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Az utolsó lap... 


Búcsú a papírtól 


A tech.net magazin utolsó számát tartja kezében a meglepett olvasó. Az alábbiakban elme- 
sélem, miért is ér véget ez a jó hírnévnek örvendő, magasszintű szakcikkeket tartalmazó, igé- 


nyes megjelenésű magazin. 


Az első kérdésük nyilván ez lenne: pénzügyi okai vannak a 
megszűnésnek? Nos, egyáltalán nem. A második kérdésre is 
tudom a választ: hogyhogy ilyen hirtelen? A válasz az, hogy 
egyáltalán nem hirtelen. Én már több mint egy éve keresem a 
megoldást arra a problémára, amit úgy neveznek: túlterhelés. 


illúziók... 


Annak idején 2000-ben, a tech.net magazin születésekor ar- 
ról álmodoztam, hogy ez egy olyan lap lesz, amibe szinte 
mindenki cikket szeretne írni, hisz mindannyiunkkal történ- 
nek tanulságos, érdekes dolgok napi munkánk során. A kifej- 
tendő témakörök száma már Microsoft technológiából is igen 
széles, és a végtelenhez tart — már csak le kell írni. 

Bennem például igen erőteljes publikálási kényszer feszült, 
úgy éreztem, hogy legalább 1000 embernek kell elmonda- 
nom mindazt a tapasztalatot, amit addigi oktatási és szakta- 
nácsadási ténykedésem során felhalmoztam. 


... és a valóság 


Sajnos a publikáló szerzők száma sohasem haladta meg azt a 
minimális létszámot, ami mellett biztosítva lett volna, hogy 
hónapról hónapra elegendő tartalommal rendelkezzünk. 
Tökéletesen alátámasztja ezt az a tény, hogy ez a lapszám is 
8 oldallal karcsúbb, mint ,szokott", bár a ,szokott" már na- 
gyon gyakran 4-4 oldal lelopását jelentette. 

Az én belső kényszerem így fokozatosan külső kényszerré 
alakult, a tech.net magazin pedig beköltözött a mindennap- 
jaimba, a szabadságom idejébe, az estéimbe — mindenhova. 
Ha éppen nem korrektúráztam, akkor cikket kellett írnom, ha 
ezzel is megvoltam, jöhetett a szerzőkeresés, a következő 
lapszám tervezése, a nyelvi lektorálás és az egyeztetés a gra- 
fikusokkal. Mindezt mellékállásban, az oktatás utáni szabad- 
időmben végeztem. 

Ezt a problémát úgy próbáltam orvosolni, hogy egy jó fél éve 
elballagtam a Microsoft Magyarországhoz: keressenek új fő- 
szerkesztőt, mert én szeretnék csöndben visszavonulni. Fél 
éves felmondási időben állapodtunk meg, és ez az idő most 
lejárt. Utódom sajnos nincs. Tehát a tech.net magazin a je- 
lenlegi formájában megszűnik létezni. 


Információs túlterhelés 


Sokat gondolkodtam, vajon helyesen döntöttem-e, és az 
utóbbi hetek tapasztalata azt mondatja velem, hogy sajnos 
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igen. Az újdonság varázsának elmúltával a tech.net magazin 
is beállt a soha el nem olvasott kiadványok sorába. Több elő- 
fizetővel beszéltem, akik már nem győzik elolvasni, amiket 
írunk. Ez pompásan találkozik azzal, hogy mi pedig nem 
győzzük megírni. Ha a matematika szabályai szerint mindkét 
oldalt elosztjuk tech.nettel, az egyenlőség nem borul fel. 


Mi lesz ezután? 


Az év eleje óta üzemel a NetAcademia Tudástár, ahová egy- 
részt folyamatosan felpakoljuk a korábbi tech.net cikkeket 
(az örökévalóságnak). Ezek az anyagok hamarosan a 
www.microsoft.com/hun/technet/ oldalról is elérhetővé vál- 
nak. Emellett a NetAcademia Tudástár lesz az a fórum, ahol 
a belső kényszerből fakadó írásaink megjelennek. Nem havi 
rendszerességgel, nem 40 oldal terjedelemben — de szakcik- 
kek. 


A tech.net tervek 


A Microsoft Magyarországtól származó információk alapján a 
keresés továbbra is folyik, tehát a papírmagazin — amennyi- 
ben sikerül megfelelő, írói vénával és komoly szakmai háttér- 
rel egyaránt rendelkező főszerkesztőt találni — reményeik sze- 
rint 2004 első felétől kezdődően ismét megjelenik. 

A magunk részéről a szakmai publikációkat eztán a Tudástár- 
ban közöljük, ahol fel lehet iratkozni az egyes témakörökre, 
és ha ott új cikk jelenik meg, emailben értesítjük az olvasó- 
kat. 

Persze tudom, hogy a papír az papír: csak ezt lehet olvasni 
buszon, fürdőkádban, valamint vezetés és bandzsi 
dzsamping közben. Éppen ezért azon gondolkodunk, hogy 
(ha kipihentük eddigi fáradalmainkat) megjelenünk egy ne- 
gyedéves szaklappal. De ez még csak annyira biztos, mint 
hogy a Matrix filmsorozat nem ért véget a harmadik résszel. 


A formától és névtől búcsúzunk tehát, de a tartalomtól nem. 
Viszontlátásra 2004-ben is! 


Találkozunk a weben és a tanfolyamokon! 
Fóti Marcell 


Főszerkesztő 
MCSE, MCT,-MCDBA, MZ/X 
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Parancssori hálózatkezelés 


már felbukkant a Netsh parancs, amivel akkor IP-címet 
állítottunk egy hálózati kártyán. Most összefoglalom a 
Netsh-val elvégezhető feladatokat, köztük néhány olyat, 
amit másképp el sem lehet végezni. Hogyan mentenék 
le másképpen egy adott gép hálózati beállításait? 


2 Remote Desktop Connection 


General " Dgiay / Local Resources ( Piogtams ! Experence 
1998 hó nam of the coinYuAót. 6! éhoost a cemosáat horn 
he drop dovn it 
Computer öleeve v 
lberrane (sőszékölss 
BPasaword 
Domain FALATRAX 

Elsave ny password 


Söve cuteni tetingi. 01 open söved comecton 








Connect J( Cancet (Hop ) ( door 











Hagyományos rendszermenedesment 
... ami már nem is annyira hagyományos 


Napjaink IT infrastruktúráinak hatékony üzemeltetése csak egy rendszer- 
menedzsment eszköz által támogatva képzelhető el. De be kell-e érnünk 
egy HW-SW leltárral, egy szoftverterítési eljárással és a többi jellemző 
funkcióval? Mi lesz például az októberi számban bemutatott 800 gépes 
feladattal, ha nincs a közelben az akkori szerző? Kerüljünk a közelébe egy 
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Select cmd (running as BROKKOLNNadministrator) - netsh 


Tee 


Netsh KT TEMETETT ETET 


í F8 jé sáfőkée gét eg Mr 
A múltkori ,Ne légy rendszergazda!" című cikkemben  SEijütákb úti ja HBA 

1 
j 





DLL 
1 DLL 
PUGHON : DLL 





4 oldal 


Terminálszolgáltatás a Windows Server 2003-ban 
Alkalmazások a távolban 

A terminálok segítségével elérhető központi kiszolgáló koncepciója napjainkban új- 
ra terjedőben van, mivel a központi felügyelet olcsóbbá teheti a nagy gépparkok 


üzemeltetését. A Windows Server 2003 Terminálszolgáltatás ennek megvalósításá- 
hoz kínál eszközöket. 








Tivoli rendszernek! 


10. oldal eln 














Crossover 














Hálózati Kábelezés 
UÚTFP, CATS; R]j45 


Ha szükségünk van egy speciális méretű hálózati kábelre... Szerelőt hí- 
vunk, mert saját magunk félünk elkészíteni? Inkább megvesszük az üzlet- 
ben? Esetleg egy , szaki" ismerősünk készíti el? Ha ezekre a kérdésekre 
igen a válasz, a cikk végére talán majd nem az lesz... 
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Az önműködő hálózat 
A UPnP hálózat segítségével megvalósítható a hálózati eszkö- 
zök automatikus csatlakoztatása és eltávolítása, a műveletek 
al semmilyen emberi beavatkozást nem igényelnek; az összes szükséges in- 
Be IP hálózat formációt [BS az eszközök hordozzák és hirdetik meg a hálózaton. 
rt; 
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A DALP rejtett szépségei — DII. EZTET HEMEZET EISTETSlel a 


A cikksorozat befejező részében három fontos témakört elemzünk. Meg- [1 ! ; 
vizsgáljuk, milyen lehetőségeink vannak a DHCP-szolgáltatás rendelkezésre 21 AK , ki! u l I 
állásának növelésére, áttekintjük a beépített monitorozó eszközöket, végül Eb E sggzltóá eleszi ES 
néhány hasznos fogást ismertetünk, amelyek a DHCP-adatbázis karbantar- e 
tását segíthetik. 


19. oldal 








Felhasználói bizalom, mint a fejlődés kulcsa 
) e Az információs társadalom fejlesztésén munkálkodó Magyarországnak szembesülni kell az- 
zal a problémával, hogy a fejlődés gátja ma már nem a rendelkezésre álló hardverek szű- 
! szi kössége, és nem is alapvetően a világhálóhoz való csatlakozás drágasága, hanem egyrészt 
az Internettel elérhető szolgáltatások kínálatának szűkössége, másrészt az a felhasználói bi- 


zalmatlanság, amely legfőbb akadálya a szolgáltatások bővülésének. 


15. oldal 
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Nbjektumorientált alkalmazásfejlesztés 


Záró gondolatok 


33. oldal 














Fejlesztő C 
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Parancssori hálózatkezelés 


mel 


Netsh 


Parancssori hálózatkezelés 


A múltkori ,Ne légy rendszergazda!" című cikkemben már felbukkant a Netsh pa- 
rancs, amivel akkor IP-címet állítottunk egy hálózati kártyán. Most összefoglalom a 
Netsh-val elvégezhető feladatokat, köztük néhány olyat, amit másképp el sem lehet 
végezni. Hogyan mentenék le másképpen egy adott gép hálózati beállításait? 


Netsh alapok 


A Netsh parancs egy keretprogram, ami olyan funkciókat lát 
el, amilyen helper DLL-ek ,alá vannak rakva". Kétféle üzem- 
módban futtathatjuk: parancssori és interaktív módban, ha- 
sonlóan például az NSLookup parancshoz. 

Parancssori üzemmódban közvetlenül beírjuk a parancs mö- 
gé az összes utasítást és paramétert, ami a végrehajtáshoz 
szükséges, például: 


 "netsh interface ip set dns local dhcp 


Interaktív üzemmódban pedig egy promptot kapunk, ahova 
akár órákon át írogathatjuk a Netsh parancsokat: 


netsh: 


Parancskészlet 

Kezdjük azzal, hogy megnézzük, milyen parancsokat támogat 
mondjuk egy Windows XP-n. Az alábbi ábrán a parancslistá- 
zó parancsot (show helper), valamint a lista elejét láthatjuk, a 
jobb oldali faszerkezet pedig az egyes DLL-ek által kiszolgált 
parancsokat mutatja. 


§. 
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B Netshhelper DLL-ek és funkcifunkcióik 


Netsh hierarchia 

Apropó faszerkezet: a parancsok (a DLL-ek mentén) logikus 
hierarchiába vannak szervezve, és úgy váltogathatunk közöt- 
tük, mintha egy könyvtárszerkezetben mászkálnák fel és alá. 
Ezt a Netsh kontextusváltásnak hívja. Van néhány parancs, ami 
a hierarchia mindegyik pontján kiadható, ezek az alábbiak: 





kele ezer 
SET valamilyen értéket beállít 
SHOW ja beá okat egyesével jeleníti meg 
DUMP j a beállításokat scriptszerűen listázza ki 
ADD többértékes változók második és sokadik értéké 
nek beállítására (pl. másosdik DNS Server-cím) 
DELETE / többértékes változók második és sokadik értékének törlése 
HELP j az adott kontextusban érvényes parancsokat listázza ki 
PUSHD / egy kontextus elmentése 
POPD i visszatérés egy elmentett kontextushoz 





Kontextusváltások 


A legegyszerűbb kontextusváltás, ha egy paranccsal , beljebb" 
megyünk, például a gyökérből az INTERFACE kontextusba: 


interface 
Vagy rövidítve: 
ak 


A parancsokat ugyanis addig célszerű rövidíteni, amíg egyér- 
telműen beazonosíthatók. Egy alap Windows XP-n csak az 
INTERFACE kezdődik i-vel, de már például o vagy p betűs pa- 
rancs kettő is van. Ha azokat rövidítjük, lehet, hogy mást csi- 
nál a parancs, mint amire gondolnánk (lásd később)! Ez a pél- 
da egyenesen az INTERFACE alatti IP kontextusig hatol le: 


A8bL8 


Kontextusból , kijönni" a .. (pont-pont) jelekkel, míg a Netsh- 
ból tetszőleges mélységből egyből kiszállni a BYE (rövidítve: 
B) paranccsal lehet. 

Két további kontextuskezelő parancs van, a PUSHD és a 
POPD, amelyeket hosszabb scriptekben érdemes használni. 
Lássunk is mindjárt egy olyan scriptet, ami kis kalandunk után 
lehetővé teszi, hogy egyetlen mozdulattal visszaállítsuk majd 
a hálózati kártyáink IP-beállításait. Tehát elmentjük a jelenle- 
gi beállításokat. 


DUMP parancs 


A hierarchia tetszőleges pontján kiadva a DUMP parancsot 
egy olyan outputot kapunk, ami annak a kontextusnak és 
gyermekeinek beállítását tartalmazza — mégpedig Netsh script 
nyelven! 

Ha a gyökérben futtatjuk, az IGMP-től az IPV6-ig minden 
beállítást lescriptel. Ha csak az IP-vel kapcsolatos beállításo- 
kat szeretnénk scriptelni, menjünk be az INTERFACE IP kon- 
textusba (7 í), és ott dumpoljunk egyet! 
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jó End of interface IP configuration 
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Az IP-beállítások mentése scriptbe (dump) 


A fenti képernyőképen nemcsak a SET parancs helyes haszná- 
latára láthatunk példát, hanem arra is, hogyan alkalmazhatjuk 
a PUSHD, POPD parancsokat egy olyan scriptben, mely 
össze-vissza nyargalászik a kontextusok között. Ugyanis a 
legelső sorban olvasható 





parancs először lementi a jelenlegi kontextust, ezután beszá- 
guld az INTERFACE IP alá, ott ügyködik néhány sort, majd a 
script legvégén POPD-vel visszaáll oda, ahol korábban voltunk. 
Ha a teljes Netsh hierarchiáról csinálunk egy dumpot, azt lát- 
hatjuk, hogy mindegyik ágba hasonlóan rohan be, ott tesz- 
vesz valamit, majd POPD-vel visszaugrik a gyökérbe, hogy a 
script következő parancsa a kályhától indulhasson el. 


Hálózati beállítások mentése Netsh scriptbe 


Elvileg a DUMP parancsnak van egy [Filenamel] paramétere, 
ahol megadhatjuk, hogy hova tegye a kész scriptet, de ez nem 
működik, ezért más módszert eszeltem ki a feladat sikeres 
végrehajtására. Parancssori mód -t fájlbairányítás! 





Az eredmény (az ipset.txt fájl tartalma) szépen felkommentez- 
ve így néz ki: 





Remélem mindenki felismeri már a fájl szerkezetét és belsejét: 
két hálózati kártyám van, az egyik neve ,Loopback", a mási- 
ké ,utp", és ezekkel dolgozik a script. 

Futtatása pofonegyszerű: 


Az is megér néhány szót, miért neveztem el a hálókártyáimat, 
s miért nem hagytam meg az alapértelmezett ,Local area..." 
nevet? 


Hálózati kapcsolatok átnevezése 

Mint azt korábban láttuk, a netsh parancsait extrém módon le 
lehet rövidíteni, és ilyen parancsokkal lehet szédíteni a tisztes 
kollégákat: 





Ezzel általában zajos sikertől elkezdve a néma hódolatig tet- 
szőleges palettán arathatunk babérokat. (Palettán babérokat? 
Iszonyú képzavar! Csak egy magyarszakos meg ne lássa!) 

Ez a parancs egyébként az utp nevű hálókártyát DHCP-re ál- 
lítja (INTERFACE IP SET ADDRESS UTP DHCP) 

Igen ám, de a rövidítés csak addig teszi helyesen a dolgát, 
amíg a kulcsszavak egyértelműen megkülönböztethetők egy- 
mástól. De miben különbözik a ,Local area connection" a 
,Local area connection 2"-től? Csak az utolsó karakterben. 
Tehát az egyértelmű azonosítás kedvéért véges-végig ki kelle- 
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ne írni a kártya nevét, különben cigányútra megy a 
parancs (ugyanis az ABC-ben előbbre lévőn jut ér- 
vényre). 

Ezzel kapcsolatban volt egy érdekes tapasztalatom: 
kiszerelt (!!) hálókártyára futott le a netsh, mert an- 
nak neve volt a legelső az ABC-ben! Mi meg csak lestük a 
meglévő kártyát, vajon miért nem engedelmeskedik a pa- 
rancsnak? A kiszerelt bezzeg engedelmeskedett! Oo 

Ennyi bevezetés után jöjjön a kártyák átnevezése: 


uk 





Rövidítve: 





(Itt a SET parancsot SE-nek lehetett csak rövidíteni, mert kü- 
lönben a SHOW-t erőlteti. Mint ha a SH előbb lenne az ABC- 
ben, mint a SE :-O Vigyázzunk a kétértelmű rövidítésekkel, ki- 
számíthatatlanok!) 


Hálózatdiagnosztika (DIAG kontextus) 


Érdekes lehetőséget rejteget a netsh a hálózatdiagnosztika tu- 
dományágából. A DIAG kontextus sokat mondó alparancsai a 
következők: 





PING Egy kijelölt elem megpingelése 

CONNECT j TCP-kapcsolat építése és bontása egy 
kijelölt elemhez 

SHOW Egy kijelölt elem beállításának megtekintése 

GUI A fenti három parancs grafikus kivitelezése 


a Help és Support Center segítségével, 
HTML kimenettel 


A kijelölhető elemeket csak felsorolom, annyi van, mint égen 
a csillag: client, computer, dhcp, dns, gateway, ieproxy, ip, 
mail, modem, news, os, version és wins. Például a 


Parancs megpingeli a gép DHCP-kiszolgálóját. Mindez grafi- 
kusan is megy (netsh diag gui): 





39 4 (em Úzresem Ejnam Gy szvat 4) üres 


Ete iuteita 





Network Diagn 








kint agyon szara ros eretemba geher EÉornahon baz raz kardot, salt , and retvant coremetora 


nme 


elernek Cent 


E netsh diag gui 
A HTML-jelentést ki-ki nézze meg a saját gépén. Jó munkát! 


Fóti Marcell 
marcellfénetacademia.net 
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" Alkalmazások a távolban / 


Terminálszolgáltatás a Windows Server 2003-ban 


Alka Ínrazások a távolban 


"7  [erminálszolgáltatás a 
. indows server 2003-ban 


A terminálok segítségével elérhető központi kiszolgáló koncepciója napjainkban újra terjedőben van, 
mivel a központi felügyelet olcsóbbá teheti a nagy gépparkok üzemeltetését. A Windows Server 2003 
Terminálszolgáltatás ennek megvalósításához kínál eszközöket. 


Bevezetés 


A Windows Server 2003 Terminálszolgáltatás segítségével 
elérhetővé tehetjük a Windows-alapú alkalmazásokat vagy a 
Windows Asztalt magát szinte bármilyen számítógépről, még 
azokról is, amelyek nem képesek a Windows futtatására. A 
Windows Server 2003 Terminálszolgáltatás a Windows 2000 
Terminálszolgáltatás alkalmazás-kiszolgáló módján alapul, és 
tartalmazza a Windows XP-ben megjelent új tulajdonságok 


megvalósítását is. 

A Terminálszolgáltatás csak a prog- 
ram felhasználói felületét továbbítja 
az ügyfélhez, az alkalmazások futta- 
tása a kiszolgálón történik. Az ügyfél 
a billentyűzet- és az egérmozgatás 
jeleit küldi vissza a kiszolgálóra. 
Minden felhasználó csak saját mun- 
kamenetébe jelentkezhet be, és csak 
ezt látja. A kiszolgáló operációs 
rendszere a felhasználó számára lát- 
hatatlanul és egymástól függetlenül 
kezeli az ügyfélmunkameneteket. 
Az ügyfélszoítver számos hardver- 
eszközön futhat, beleértve a számí- 
tógépeket és a Windows alapú ter- 
minálokat. Egy kiegészítő szoftver 
segítségével más eszközök, például 
Macintosh számítógépek vagy UNIX 
alapú munkaállomások is csatlakoz- 
hatnak a terminál-kiszolgálóhoz. 

A Terminálszolgáltatás használata a 
következő előnyökkel jár: 


H Gyorsabban elérhetővé teszi 
az eszközök számára a Win- 
dows XP rendszert. A Termi- 


A [indorws Server 
2003 Terminálszolgál- 
tatások használata 
sok előnnyel jár: 
segítségével 
központosítható az 
alkalmazások 
felügyelete, és a 
[Windows alkalmazá: 


sok számos platform: 


ról elérhetővé válnak. 


nálszolgáltatás segítségével áthidalhatjuk azt az időtar- 
tamot, amíg a régi eszközöket a Windows XP 
Professional rendszerrel frissítik: , virtuálisan" biztosít- 
ja a Windows XP Asztalt a számítógépnek nem tekint- 
hető eszközök, illetve az olyan számítógépek számára 
is, amelyek hardvere nem felel meg a teljes Windows 
XP operációs rendszer helyi futtatásához. A Terminál- 
szolgáltatás ügyfélszoítvere számos különböző plat- 
form számára elérhető, beleértve az MS-DOS-t, a Win- 
dows alapú terminálokat, a Macintosh és a UNIX 
rendszereket. (Az MS-DOS, a Macintosh és a UNIX 


alapú számítógépekhez kiegészítő szoftver szükséges.) 
A Terminálszolgáltatás segítségével a Windows Server 
2003 számítási teljesítménye és szolgáltatásai válnak 
elérhetővé az újonnan megjelent, kisméretű és korlá- 
tozott kapacitású eszközökről is (például Pocket PC) 

A Az adatokhoz való hozzáférés kisebb sávszélességet 
igényel. Terminálkiszolgáló használatával, a nagy 
adatmennyiséggel dolgozó alkalmazásokat korlátozott 
sávszélességet biztosító környezetben is futtathatjuk 
(telefonvonal vagy megosztott WAN kapcsolat), mivel 
így az adatok helyett csak azok képernyőn megjelenő 
képét kell átvinnünk a hálózaton. 

A Biztosítja a meglévő hardvereszközök által nyújtott 
összes lehetőséget. A Terminálszolgáltatás kiterjeszti 
az elosztott feldolgozás modelljét, hiszen a számítógé- 
pek működését egyszerre sovány ügyfél módban, illet- 
ve az összes szolgáltatást futtató személyi számítógép 
módban is lehetővé teszi. A számítógépek a megszo- 
kott módon használhatók a meglévő hálózatokban, de 
sovány ügyfélként is képesek működni és a Windows 
XP Professional Asztalt emulálni. 

A Központosítja a programok kezelését. A Windows 
Server 2003 rendszert használó számítógépen futó 
Terminálszolgáltatás az összes programfuttatást, adat- 
feldolgozást és adattárolást a kiszolgálón hajtja végre, 
központosítva ezzel a programok kezelését. A Termi- 
nálszolgáltatás minden ügyfél számára biztosítja a 
programok aktuális verzióihoz való hozzáférést. A 
szoftvert csak a kiszolgálóra kell telepíteni, nem pedig 
a szervezet összes számítógépére, csökkentve ezzel az 
egyes számítógépek írissítésével járó költségeket. 

A Távfelügyeletet biztosít. A Terminálszolgáltatás lehe- 
tővé teszi a Windows Server 2003 rendszert futtató ki- 
szolgálók távoli felügyeletét, biztosítva ezzel a rend- 
szergazdák számára a kiszolgáló bármely ügyfélről 
történő távoli kezelését WAN hálózaton vagy telefo- 
nos kapcsolaton keresztül is. 


A Windows Server 2003 Terminálszolgáltatás számos új tulaj- 
donsággal és funkcióval rendelkezik a korábbi verzióhoz ké- 
pest, a cikk további részében ezeket fogjuk sorra venni. 

Az ügyfélprogram újdonságai: 


AA Továbbfejlesztett felhasználói felület 
A Ügyfélerőforrások átirányítása 
A Ügyfelek telepítésével kapcsolatos tulajdonságok 


A kiszolgáló újdonságai: 
HA Továbbfejlesztett kiszolgáló-felügyeletet 
TA Biztonsági fejlesztések 
TH Munkamenet-nyilvántartás 


Az ügyfélprogram tulajdonságai 
A Terminálszolgáltatás ügyfélprogramja számos újdonságot 
tartalmaz a korábbi kiadásokhoz képest. 


H Távoli asztali kapcsolat (Remote Desktop Connection, 
RDC) - Az RDC program segítségével csatlakozhatunk 
mind a Windows XP Professional gépeken futó Távoli 
asztal szolgáltatáshoz, mind pedig a Terminálszolgál- 
tatás régebbi verzióihoz (Windows NT 4.0 Terminal 
Server Edition és Windows 2000). Az RDC program az 


ERTSE E Et EE 





parancs beírásával, vagy a Start menüből indítható: 
Start 2 Programok 2 Kellékek 2 Kommunikáció 2 Távoli 
asztali kapcsolat 


kö nejed azt) 


Computer: olficetw AV 


5 Csatlakozás távoli számítógéphez az RDC program se- 
gítségével 


A távoli kapcsolatok beállításai 


A távoli kapcsolatok különféle opciói a Beállítások gomb se- 
gítségével érhetők el. A megnyíló tulajdonságlapon megadhat- 
juk a bejelentkezéssel, a megjelenítéssel, a helyi erőforrások- 
kal és a munkamenet létrehozáskor automatikusan elinduló 
programokkal kapcsolatos adatokat. 


tech.net map dó áá ű ív db Tb 





Display Local Resources  Prograrns Experience 


settinge 
Type the name of the computer, or choose a cormputer Írom 
the drop-dowm list. 


Computer: officefw 
User name: administrator 
Password: 


Domain. FáLATRAX 








7] 8ave my password 








etting. 
s § 
] Save current settings, or open saved connection. 


Connect Cancel Help Options A 





5 A távoli kapcsolat beállításai 


Az önálló Kapcsolatkezelő (Connection Manager) már nem 
létezik, minden funkcióját közvetlenül az RDC valósítja meg. 
Segítségével a felhasználók és rendszergazdák elmenthetik és 
betölthetik a kapcsolatok beállításait tartalmazó, rdp kiterjesz- 
tésű fájlokat. Az elmentett jelszavak biztonságos tikosítással 
kerülnek tárolásra, és csak azon a számítógépen használha- 
tók, amelyen mentésre kerültek. 


Ügyfél erőforrások átirányítása 


A Távoli asztali kapcsolat program segítségével számos adat- 
típus átirányítását megvalósíthatjuk. Biztonsági okokból min- 
den átirányítás az ügyfélen és a kiszolgálón is letiltható. Fi- 
gyelmeztető üzenet jelenik meg a fájlrendszerre, valamely 
portra vagy smart cardra vonatkozó átirányítási kérelemkor; a 
felhasználó megszakíthatja a kapcsolatot, vagy letilthatja az 
átirányítást. 


A következő átirányításokat állíthatjuk be: 


A Fájlrendszer — Az ügyfél meghajtói (a hálózati meghaj- 
tók is) elérhetők a kiszolgálói munkamenetből. Az en- 
gedély egyszerre az összes meghajtóra vonatkozik, 
ráadásul alapértelmezés szerint a kiszolgálói munka- 
menetben Everyone 5 Full Control jogosultsággal je- 
lennek meg az ügyfélgép meghajtói, így az átirányítás 
használatához némi óvatosság szükséges. 

AA Portok — Az ügyfél soros portjai elérhetővé tehetők a 
kiszolgálói munkamenetből, így a kiszolgálón futó 
szoftverek hozzáférhetnek az ügyfél bizonyos hardver- 
eszközeihez. 1 

A Nyomtatók - Az ügyfél valamennyi telepített nyomta- 
tója (a hálózati nyomtatók is) elérhető a kiszolgálói 
munkamenetből (a Windows 2000 Terminálszolgálta- 
tás csak a helyi nyomtatók átirányítását tette lehetővé). 
Az átirányított nyomtatók könnyen értelmezhető nevet 
kapnak. 
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Terminálszolgáltatás a Windows Server 2003-ban 


HA Hangok - A hibaüzenetekhez kapcsolódó hangjelzé- 
sek, vagy például az új elektronikus levél érkezését jel- 
ző hangok átirányíthatók az ügyfelekre. 

A Smart Card bejelentkezés — A Windows rendszer be- 
jelentkezési adatait tartalmazó smart card használható 
a Windows Server 2003 távoli munkamenetbe történő 
bejelentkezéshez is. A funkció használatához olyan 
ügyfélrendszer szükséges, amely önállóan is képes a 
smart card kezelésére (Windows 2000, Windows XP, 
Windows CE .NET) 

AA Windows billentyűkombinációk — Az ügyfél a Win- 
dows billentyűkombinációkat (Alt-tab, Ctrl-esc stb.) 
alapértelmezés szerint továbbítja a távoli munkame- 
netnek. A Ctrl-alt-del billentyűkombinációt azonban 
biztonsági okokból mindig az ügyfél dolgozza fel. Az 
átirányítás működik Windows 2000 terminál kiszolgá- 
ló esetén is, de csak NT alapú ügyfél operációs rend- 
szerrel (Windows 9x-szel nem). 

H Időzóna -— Az RDC ügyfél képes az időzónára vonat- 
kozó adatok automatikus átadására, illetve a felhasz- 
nálók manuálisan is beállíthatják a megfelelő időzó- 
nát. Így a különböző időzónában lévő felhasználók 
egyetlen kiszolgálót használhatnak. 

A Virtuális csatornák — A virtuális csatornákon keresztül 
adatokat továbbíthatunk az ügyfél és a kiszolgáló kö- 
zött. 


KET reg Sal] 


General. Display Local Resources Programs Experience 


Remote computer sound 


n 
FÜS Bring to this computer 
Hz 


rd 
Apply Windows key combinations 
Hg] (for example ALT:TAB) 
In full screen mode only 


cal devices 


ED — Connect automatically to these local devices when logged on 
Vej to the remote computer: 


Disk díves 
Printers 

















Serial ports 
7] Smart cards 




















Connect Cancel Help ( Options ek 





B Átirányítások 


Ügyfelek telepítése 


A Távoli asztali kapcsolat (RDC) program a Windows XP és a 
Windows Server 2003 része. Más ügyfélplatformokra történő 
telepítéshez a következő lehetőségek valamelyikét választhat- 
juk: 

TH A Microsft Systems Management Server (SMS) vagy a 
csoportos házirendek segítségével publikáihatjuk a 
Windows Installer alapú RDC csomagot. 

HA A Windows Server 2003 számítógépen (vagy a Win- 





dows 2000 kiszolgálón) megosztást hozunk létre a te- 
lepítőcsomag számára. 

AA Telepíthetünk közvetlenül a Windows XP vagy a Win- 
dows Server 2003 CD-ről, ha a telepítőmenüből az 
Egyéb feladatok végrehajtása (Perform Additional 
Tasks) pontot választjuk. 

AA Az RDC letölthető az (RDC] webhelyről. 


Az RDC Windows CE verziója 


A Windows CE .NET Platform Builder tartalmazza az RDC 
Windows CE verzióját, így a hardvergyártók beépíthetik azt 
termékeikbe. 

A kiszolgáló újdonságai 

A Terminálszolgáltatás kiszolgálói oldala is számos újdonsá- 
got nyújt, a legfontosabbak a következők: 

A Távoli felügyelet (Remote Desktop for Administration) 
— A távoli felügyelet a Windows 2000 Server Terminál- 
szolgáltatás távfelügyeleti módján alapul. A Windows 
2000 Server esetében rendelkezésre álló két virtuális 
munkamenet mellett lehetőség van arra is, hogy a kon- 
zol (session 0) munkamenethez csatlakozzunk távol- 
ról. A konzol munkamenethez egyidőben csak egyet- 
len felhasználó csatlakozhat, ha ezt egy távoli munka- 
menet foglalja el, akkor lokálisan már nem lehet a gép- 
re bejelentkezni. A konzol munkamenethez a Remote 
Desktop MMC beépülő modul segítségével, vagy az 
mstsc program /console kapcsolójának felhasználásá- 
val csatlakozhatunk. 

A A távoli asztal és a Terminálszolgáltatás aktiválása — A 
Windows 2000 Server esetében a terminálszolgáltatást 
két üzemmódban futtathattuk (alkalmazás-kiszolgáló 
és távfelügyeleti mód), míg a Windows Server 2003- 
ban a távfelügyelet és a Terminálszolgáltatás két elkü- 
lönített, önállóan beállítható komponens. A távoli 
felügyelet a Rendszer tulajdonságpanel Távoli haszná- 
lat (Remote) lapján aktiválható. 


Advanced 
medemoto 2 


General Hardware 


System Restore 


Computer Name 
Automatic Updates 


5 meg Selectthe ways that this computer can be used Írom another 
location. 


istance 





Allow Remote Assistance invitations to be sent frorn this computer 


Learn more about Remote Assistance. 


Desktop 





Allovv users to connect remotely to this computer 


Full computer name: 
brokkoli netacademia Írn 


Learn more about Remote Desktop. 


Select Remote Users... 


5 A távfelügyelet engedélyezése 


A Terminálszolgáltatás aktiválásához pedig a Terminal Server 
komponenst kell feltelepítenünk a Programok telepítése és tör- 
lése (Add/Remove Programs) varázsló segítségével. 


Windows Components Wizard 


Windows Components 
You can add or remove components of windows. 





To add or remove a component, click the checkbox. A shaded box means that only 
part of the component will be installed. To see whats included in a component, cíick 










Details. 
Components: 
] 2J0ther Network File and Pint Services 00MB aj 
Ce Remote Installation Services 20MB 
EZÉ Remote Storage 35MB 









0.0 MB 
namR I 


Terminal kézi 

VÉT erminal Server [ ineneinn 

Desciiption:. Configures this computer to allow multiple users to run one or more 
applications remotely. 

Total disk space reguired 

Space available on disk: 


29MB 
2026.1 MB 











E A Terminal Server telepítése 


További felügyeleti eszközök 


E Csoportos házirend -— A Terminálszolgáltatás tulajdon- 
ságainak beállításához használható a csoportos házi- 
rend. Ennek segítségével lehetőség van kiszolgálócso- 
portra vonatkozó paraméterek együttes beállítására is. 
Active Directory Service Interfaces — Az ADSI csato- 
lófelület segítségével programból férhetünk hozzá a 
Terminálszolgáltatás felhasználóira vonatkozó beállí- 
tásokhoz (például home mappa, hozzáférési jogok). 
Single Session Policy — A Single Session Policy beállí- 
tásával a rendszergazdák egyetlen munkamenetre kor- 
látozhatják a felhasználók hozzáférését, még kiszolgá- 
lócsoportok esetében is. 

Hibaüzenetek — Több mint 40 új hibaüzenet segíti az 
ügyfélkapcsolatokkal összefüggő problémák gyors 
diagnosztizálását. 


Biztonsággal kapcsolatos fejlesztések — A 
Terminálkiszolgáló biztonsági modellje job- 
ban illeszkedik a Windows kiszolgálóknál 
megszokott rendszerbe. 

Remote Desktop felhasználói csoport — A 
Remote Desktop Users felhasználói csoport tagjai jo- 
gosultak a Terminálszolgáltatáshoz való csatlakozásra. 
128 bites titkosítás — Alapértelmezés szerint a termi- 
nálkiszolgálóval való kapcsolat 128 bites, kétirányú 
RCA titkosítással biztosított, ha az ügyfél támogatja a 
128 bites titkosítást (az RDC alapértelmezés szerint 
128 bites). Lehetséges azonban a régebbi alacsonyabb 
titkosítási szintet biztosító ügyfelek csatlakozása is, ha 
ezt le nem tiltjuk. 

Szoftverkorlátozó házirendek — A szofítverkorlátozó 
házirendek segítségével a rendszergazdák beállíthat- 
ják, hogy a terminálkiszolgálón (vagy bármely más 
Windows 2003 kiszolgálón) a megadott felhasználók 
csak bizonyos alkalmazásokat futtathassanak. 
Munkamenet nyilvántartás (Session Directory) — A 
terminálkiszolgálók farmokba szervezhetők, így a ter- 
heléskiegyenlítéssel működő fürt hibatűrő szolgáltatást 
biztosíthat a felhasználóknak. A munkamenet nyilván- 
tartás biztosítja a felhasználóknak, hogy a farmon be- 
lüli elhagyott munkamenetükhöz csatlakozhassanak 
vissza. 


- 


Összefoglalás 


A Windows Server 2003 Terminálszolgáltatás segítségével 
megbízható, jól skálázható, és könnyen felügyelhető kiszolgá- 
ló alapú rendszer építhető fel. Az új opciók segítségével job- 
ban kihasználhatjuk a kis sávszélességű kapcsolatokat, így a 
mobil, illetve kis teljesítményű eszközök is jól használhatóak. 
A továbbfejlesztett ügyfél csatolófelület számos átirányítástí- 
pust támogat, fejlődött a kiszolgálók felügyelete és biztonsága. 


Szerényi László 
szerenyi.lomet.hu 


http://vilagokorseg.hu 
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Hagyományos 
. rendszermenedesment 


... ami már nem is annyira hagyományos 


Napjaink IT infrastruktúráinak hatékony üzemeltetése csak egy rendszermenedzsment eszköz által tá- 
mogatva képzelhető el. De be kell-e érnünk egy HW-SW leltárral, egy szoftverterítési eljárással és a 
többi jellemző funkcióval? Mi lesz például az októberi számban bemutatott 800 gépes feladattal, ha 
nincs a közelben az akkori szerző? Kerüljünk a közelébe egy Tivoli rendszernek! 


Emlékeztetőül: a feladat az volt, hogy operációs rendszer 
upgrade első lépéseként a munkaállomások C:V meghajtóján 
lévő ".DOC és ".XLS fájlokat (továbbiakban Office állomá- 
nyok) át kell másolni a D:Y meghajtóra. Akkor egy scriptes 
megoldást olvashattunk, ami a Windows Scripting Host 
(WSH) környezetet felhasználva végzi el a mentést. A feladat 
rendszermenedzsmentes megoldását az IBM Tivoli [sysmgmt] 
rendszerének használatával mutatom be. Pontosabban a Tivo- 
li Configuration Manager modul az, ami segítségünkre lesz, 
ugyanis a teljes körű megoldást kínáló rendszereknek csupán 
egy részterülete cégeink munkaállomásainak konfiguráció- 
menedzsmentje. 


Az infrastruktúra 


Sok mindent meg lehet oldani Group Policyvel, láthattuk, 
hogy a WSH mire képes, vannak eszközök távoli telepítésre és 
képernyőátvételre is, viszont ha nem rendelkezünk minden 
egyes komponensből (munkaállomás operációs rendszertől az 
adatbáziskezelőig) az aktuális évszámnak megfelelő verzió- 
val, vagy éppen sokvégpontos környezetre kell felügyeletet 
gyakorolnunk, netalán platformjaink sokszínűsége a tavaszi 
rét színkavalkádjával vetekszik — teljes körű rendszerme- 
nedzsment nélkül nem ússzuk meg. 

Az előző, bekezdésnyi mondatot kipihenendő folytassuk a kö- 
vetkéző szakaszt a megvalósítás áttekintésével. 


A megoldás 


A kezdeti döbbenet után logikusan három részfeladatra bont- 
hatjuk teendőinket: 

1. Leltározás: ahol összegyűjtjük az Office állományokat, 
azok pontos elérési útjával. 

2. Másolási feladat kijelölése: nem a felhasználó által lét- 
rehozott állományok kiszűrése, majd a fájlmásolás de- 
finiálása 

3. Másolás: hadd menjen! 


Több eltérő feladat, amelyek lehetőleg egyből kövessék egy- 
mást a végpontokon, ugyanis egy kéthetes állományleltár 
alapján végrehajtott mentés várhatóan nem erősíti az IT üze- 
meltetési csapat pozícióját a cégen belül. Tivolink Activity 
Plannerre keresztelt szolgáltatása megkímél bennünket a 
,Sszőnyeg szélétől", ugyanis a Configuration Manager és a Ti- 
voli Framework keretrendszer által biztosított minden eszközt 
képes egy activityvé vagy planné vagy tervvé összefogni — ki- 


nek ahogy tetszik. Az egyes részfeladatok között sorrendisé- 
get, kapcsolatot definiálhatunk, majd az egészet ráengedhet- 
jük akár az összes munkaállomásunkra: a sorrendet és kapcso- 
latot minden egyes végponton tartani fogja. 


$ Activity Plan Editor [ BackupDocsáActívity 1 


File Edit View Help 
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E Tervünk, a maga vizuális valóságában 


A terv elemei — sorrendben balról-jobbra: 
(1 InventoryScan: a fájlok leltárjának előállítója 
(2) Task: a leltár alapján készít egy .BAT állományt, ami a 
mentést fogja végezni 
(3) SoftwarePackage: elindítja a létrehozott script-et 


Kaméleon van a kezünkben? 


Szeretném hangsúlyozni, nem ez az egyetlen módja annak, 
hogy teljesítsük a küldetést és vezetőnktől, megrendelőnktől 
megkapjuk a hivatalos, ám mégis elismerő üzenetet: 
"MISSION COMPLETED SUCCESFULLY". A Tivoli eszköztárá- 
ban épp az a csodálatos, hogy utat enged a kreativitásnak, tel- 
jesen testre szabhatjuk, többféle megoldási lehetőséget kínál, 
még az ilyen nem szokványos feladatokra is. A lehetséges 
megoldási alternatívák között még talán egyszerűbb is akad: 
amikor a kezdeti leltározás után, a másolandó fájlok listáját 
közvetlenül a végponton generáljuk a Tivoli Inventory által 
készített állományból. Ez utóbbi a Korn Shell igen gazdag szö- 
vegkezelési képességeit igényli, és annak ellenére, hogy egy 
taskkal még ilyen shell scriptet is futtathatunk (Windows- 
on!!!), mégsem ezt a rövidebb változatot használtam, hanem 
inkább egy látványosabbat. 


Első lépés részletesen 


Az alábbi ábra magáért beszél: már ebben a lépésben lehető- 
ség van alkönyvtárak kizárására és természetesen fájlmaszkok 
definiálására. A leltározás befejeztével RDOBMS adatbázisunk 
gyarapodik, esetleg módosul az Office állományok adataival: 
név, méret, teljes elérési út, állománylétrehozási és -hozzáfé- 
rési információk. Ellenőrzőösszeget is kérhettem volna, de ar- 
ra most nincs szükség. Ezt SOL utasításokkal és a Tivoli eszkö- 
zeivel lekérdezhetjük, de ne szaladjunk előre, beszéljen most 
a látvány: 










Scan Options Files 





I 
) Specifyihe pe of information to gather dunng he scan Specifytne tpes offles to neiude or eselude in the scan 


CI Ezecutatte files only 





I Scan for installed products using signature matching 

( Scanfles for header information 6 indiude O Exetude 

EZ Scanfles for basic informabon 
(TI Applv tustom fiter 


Generate checksum 
(04ay affect scan performance) 


None . 
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5 Szoftverleltár testreszabása 


Második lépés részletesen 


Ennek végeztével addig kell eljutni, hogy a célgépeken ott le- 
gyen egy futtatható állomány, — célszerűen egy .BAT fájl, — 
amit majd lefuttatva abszolváljuk a feladatot. Itt jön képbe a 
Tivoli, ,task" nevezetű eszköze, ami egy kamikaze elszántsá- 
gával felvértezve lefuttat bármit, bármely menedzselt erőforrá- 
son. Le kell tehát kérdeznünk az adatbázist, és abból elő kell 
állítani a .BAT állományt. Ezt nem célszerű a végponton csi- 
nálni, a feladatra központi Tivoli szerverünk örömmel vállal- 
kozik, viszont így nem szabad elfelejteni az előállt fájl vég- 
pontra való juttatását sem. 


Írjunk tehát egy kis scriptet, amit a szerveren fog a taskunk fut- 
tatni: 
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Magyarázat: 


(1) ,DocsOnC" lekérdezés szűrése az aktuális 
végpontra, amit paraméterként kap meg auto- 
matikusan a task. 

(2) Lekérdezés kieresztése a karámból, hogy az- 
tán soronként végighaladva rajta — némi konverzió után 
— előállítsa a másolást végző állományt. 

(3) Az előállt copytod.bat elküldése a munkaállomásra. 


Kész a script, adjuk oda a task-nak: 





SecondPhase 








Task Properties: 
Platforms Supported: Koles Reguired to Execute Task- 
T Generic 
TT SPARC/ SunOS 

] TT SPARC Solaris 

TT PA-RISC ! HPUX 9 

! TT PA-RISC fHPUX 10 

]w TT IBM RSf6000 / AIX 3 
FF. IBM RS/6000 J AIX 4 


remote reboot 
senior 
per 


Execution Privileges: 


Group Name: 











Task History and Comments: 
Task Name : tl.test-region.sys/SecondPhase 
TaskCreated  -SatNov 1 21:00:54 2003 
TaskCreatedBy  : asarandi€giivtest01 
Task Files 
aix4-rt tivtest01 
Distribution Mode. : ALI [on Host 


Task Comments 











a Milyen platform is a szerver? Ki sem fér a választék... 


Harmadik lépés részletesen 


Ha valakinek hiányérzete támadt volna a Tivoli eszközeinek 
számát illetően, azt nem hagyom tovább keseregni, engedjék, 
engedjétek meg, hogy bemutassam a , Software Distribution" -t. 
Ő fogja Nekünk lefuttatni a másoló .BAT programot. Készí- 
tünk egy ún. SoftwarePackage-et, aminek semmi egyebet nem 
mondunk, minthogy a C:Xcopytod.batot futtassa le: 






CARunBackupSarot-spb] 
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E Software Package Editor madártávlatból 
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Essünk neki a munkaállomásoknak 


Hátradőlés előtt már csak egyet kell tennünk, 

ráereszteni a gépekre a tervet és nyomon követni ho- 
gyan terjed szét cégünk hálózatán művünk. Mint 
ahogy eddig mindent, ezt is megtehetjük parancssor- 


ból és grafikus felületről (Activity Planner Monitor) is. Ez utób- 
bit választottam, ahol demonstrálom a megoldás talán egyik 
legnagyobb előnyét, a NYOMONKÖVETHETŐSÉGET. Ponto- 
san tudjuk, hol tartunk, mely gépeken, mely fázisban jár a 
végrehajtás. 
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ST BEVSÖZÉBZOKTSE AMAZT ZA eszem ezzel ré tér eza 


A A végén. Ezt jól megcsináltuk... 


Amit nem láttunk 


Néhány olyan funkció, ami a háttérben zajlik a csomag teríté- 
se alatt és szót érdemel: 
HR MDIST2: segítségének köszönhetően nem kell minden 
végpontnak a kiküldés pillanatában bekapcsolva len- 
nie, ha a beállított lejárati időn belül feljelentkezik a 
hálózatra, a Tivoli automatikusan leküldi rá az akár na- 
pokkal korábban elengedett csomagot. 
A Wake-On-Lan: biztosíthatja pl. az éjszakai terítést. 








Haladó tanfolyamosoknak 


Amennyiben abban a szerencsés helyzetben talál bennünket 
ez a feladat, hogy nem magasodik fölénk vezetőnk — esetleg 
igen tisztelt Főszerkesztőnk — egyik kezében a befejezés — a 
cikkleadás — legkésőbbi dátumát mutató táblával, másikban 
egy ostorral, finomíthatjuk munkánkat az alábbiakkal: 

A D:V ellenőrzése: Létezik? Helyi meghajtó? Írható? Van 
elég hely? Ezekre a Tivoli HW-SW leltára választ ad. 

A Felhasználói értesítés: feldobhatunk a könyvelés ked- 
venc Gizikéjének egy ablakot, hogy végeztünk az el- 
múlt 5 évben készített Office állományainak — annak a 
háromnak - lementésével, bármelyik percben megér- 
kezhet a Takarító Brigád a maga kissé nyers, de 
hasznos eszközével, a , format c:" —vel. 

A Újabb leltározás a folyamat végén, hogy teljesen biz- 
tosak legyünk a sikerességben. 

A A teljes folyamathoz feltételeket is definiálhatunk, így 
néhány kattintással kizárhatjuk a körből a már 
upgrade-elt munkaállomásainkat. 

A Tömörítés: mielőtt másolnánk, tömörítsük össze az 
Office állományokat, így nem zúdítunk, akár több 
száz állományt a D:X-be. 

A Egy központilag létrehozott Windowsos megosztásra 
való másolás, gépnevenként külön alkönyvtárba. 


Jöhet a karosszék? 


Ha az ilyen vagy hasonló feladatot, könnyen, rugalmasan, 
külső erőforrás nélkül kipipálhatjuk, hátradőlhetünk a 
rendszerüzemeltetők képzeletbeli karosszékében és elisme- 
rően tekinthetünk a kis piros Tivoli ikonra a taskbaron. Ha 
nem rendelkezünk rendszermenedzsment eszközzel — az pó- 
tolható. Annál viszont kevés elkeserítőbb helyzetet tudok fel- 
sorolni, ha van ilyen segédünk, viszont az nem használható 
kellőképpen rugalmasan az ilyesfajta feladatok elvégzéséhez. 
Ugyanis 6 éves ,rendszermenedzsmentes" múlttal és három 
gyermekkel a hátam mögött bizton állíthatom: ha elképzeljük 
a lehető legvadabb üzleti, vezetői igényt, az elkövetkezendő 
1 évben a nagybetűs ÉLET túltesz majd ezen is. 


Sárándi Attila 

asarandigindex.hu 

Magyar Tivoli Felhasználók Egyesülete 
Hungarian Tivoli User Group 
hungariantugOlotus.extranet.com 
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Ha szükségünk van egy speciális méretű hálózati kábelre... Szerelőt hívunk, mert sa- 
ját magunk félünk elkészíteni? Inkább megvesszük az üzletben? Esetleg egy , szaki" ismerősünk készí- 
ti el? Ha ezekre a kérdésekre igen a válasz, a cikk végére talán majd nem az lesz... 


Aki elméleti (szoftver) síkon már magas szintre képezte ki ma- 
gát a hálózati rendszereket illetően, ám az idevágó fizikai 
(hardver) megoldásokhoz még nem áll olyan közel, mint sze- 
retné... nos, akikre igaz eme állítás, azoknak szeretnék egy kis 
információt nyújtani az egyik legalapvetőbb és legelterjedteb- 
ben használt hálózati hardvereszközről: az UTP kábelről. 
Hogy miért pont ezt választottam? Mert ez jutott éppen az 
eszembe, és mert nemrégiben többször is előjött egy-két, a ká- 
belezésre visszavezethető probléma. 


Miről is lesz szó? 


Az Ethernet alapú hálózati megoldást követve, a CAT5-ös 
(CATegory 5) UTP (Unshielded Twisted Pair) kábelek, szabvá- 
nyos R]45-ös csatlakozóval (szakzsargon szerint: 8-as pucuká- 
val) szerelt változatával foglalkozom. 


Ugrás a ,mélyvízbe"... 


A ,8-as pucuka" talán elegendően informatív ahhoz, hogy ki- 
derüljön belőle, hogy egy nyolc eres kábeltípusról van szó, 
amiből az említett hálózati szabványban mindössze két ér- 
párt, azaz négy vezetéket használunk. Az UTP betűszóból 
kiemelten fontos a T, azaz a Twisted (csavart) kifejezés. Mivel 
nagyírekvenciájú jeleket viszünk át a kábelen, elengedhetetle- 
nül fontos, hogy az egyes erek ne viselkedjenek hosszú kife- 
szített antennaként — mindenféle környezeti zavart összeszed- 
ve és sugározva -, illetve egymást se zavarják a közösen, 
egymás mellett" megtett út során. 

Erre a legegyszerűbb és legjobb megoldás, ha összecsavarjuk 
őket. Ez egészen pontosan úgy néz ki, hogy a nyolc vezeték- 
ből, kettesével véve, négy pár van képezve, amely párokban 
egy-egy vezetéket egymással összetekerünk, és végül az így 
létrejött négy pár egymással is össze van tekergetve a tökéle- 
tes hatás érdekében. Ezzel minimálisra csökken az egyes erek 
közti interferenciahatás és jelkisugárzás sem lép fel. A CAT3 
szerint 10-15 csavarás kell méterenként, míg ez szám a CAT5- 
nél 20-30. Felmerülhet a kérdés, hogy összecsavarva vajon 
miért nem zavarják egymást? (Egyébként zavarják, de csak a 
megengedett szint alatt.) 

Azért nem, mert az ,egyenes antennaszakaszok" gyakorlatilag 
megszűnnek, azaz nincs egyetlen ,egyenes" pontja sem a ká- 
bel ereinek. Szabályosan elvégzett sodrással elérhető, hogy az 
elemi kis csavarokban fellépő indukciók kioltsák egymást. 
Emiatt erősen érzéketlenné válik a környezeti zavarforrásokra 
nézve, illetve alkalmatlanná válik a rajta futó jel sugárzására is. 
Ez persze csak egy bizonyos frekvenciahatáron belül érvénye- 
sül. Van azonban még egy érdekes , zavartényező" is, ami vi- 
szont nem küszöbölhető ki. Ez pedig abból adódik, hogy a ká- 
belen átjutó jel folyamatosan ellenállásba ütközik (kábelünk 
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ebben a példában nem szupravezető) így a két vége között el- 
lenállás mérhető. Emellett a két szigetelt kábel-ér (szorosan 
egymás mellett) megvalósítja a ,két vezető fegyverzet között 
elhelyezkedő szigetelő réteg"-et, ami nem más, mint a kon- 
denzátor. Ezek így együtt — végig a kábelen — egy jó hosszú 
sor, elemi RC tagokból álló láncolatot alkotnak. Az RC tag 
(ResistorsCapacitor) pedig az elektronikában használt egyik 
szűrőkapcsolás. 
Emiatt van, hogy nem lehet végtelen hosszú UTP kábel két há- 
lózati eszközöm között, hanem százméterenként csinálnom 
kell valami forradalmat, különben a jel torzul, vagy elvész. A 
kábel csillapítása erősen függ az alkalmazott anyagoktól: A 
legjobb minőségű jeltovábbítást a merevszálas tiszta rézkábel- 
lel érhetjük el. A szabvány kitalálói úgy gondolták, hogy 
egyezményes színjelekkel látják el az egyes ereket, így segít- 
ve a pontos kábelezés kialakítását. A színpárok a következők: 

A Narancssárga és narancssárgacsíkos-fehér 

A Zöld és zöldcsíkos-fehér 

A Kék és kékcsíkos-fehér 

A Barna és barnacsíkos-fehér 


A párok tagjai természetesen egymással vannak összetekerve, és 
színről könnyen felismerhető, hogy melyik melyikhez tartozik. 

Visszatekintve a múltba látható, hogy többféle — egyre erősö- 
dő — igényt támasztottunk az UTP kábelekkel szemben az 
idők folyamán. A specifikáció együttes családneve: 1OBaseT, 
de csak CAT5-ig. Régebben még elég volt, ha a 10 Mbit/sec- 
os (max. 16 MHz-es jel) hálózatot átvitte, de mára már a 100 
Mbit/sec (100 MHz-es jel) vált általánossá. Sőt, az 1000 Mbit- 
et teszik rézkábelre is, azaz van gigabites ,nem-üveg" kábel. 
(Meg persze egy sor új szabvány: CAT5e, CAT6, CATZ, stb.) 

A kis sebességnek még a CAT3-as is megfelelt, a CAT5-ös vi- 
szont magasabb követelményi szintet teljesít, ezért pontosan 
meg van határozva, hogy mely ereket milyen kötési rendben 
használhatunk. 

Ezzel válik lehetővé, hogy a , 100 Mega full duplex" azaz ef- 
fektív 200 Mbit/sec hiba nélkül átmenjen rajta. Le van ám ír- 
va szépen, hogy milyen színű ereket, milyen sorrendben, ho- 
gyan tehetünk bele az RJ45-ös csatlakozóba. Még az is meg- 
határozott, hogy mekkora maximum hosszban tekerhetjük 
szét az egymással összesodort ereket a csatlakozó felhelyezé- 
se előtt, hogy minél rövidebbek legyenek a kialakult egyenes 
szakaszok. (Persze nem kell azért szőrszálhasogatni, a lényeg, 
hogy a lehető legkevesebb , szétcsavarást" alkalmazzuk.) 

De mielőtt felhelyezzük a ,pucukát" a ,krimpelő" fogóval a 
kábel végeire, nézzük meg, hogy mit mivel kell összekötni, 
hogy kétirányú kapcsolatot teremthessünk két eszköz között. 
Van ugye egy vevő meg egy adó mindkét oldalon. Jelük 
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egyezményesen: RX és TX. R mint Receive és T mint 
Transmit. Mindkettő két vezetéket használ, hogy az 
áramkör létrejöjjön, így összesen négy ér kell ahhoz, 
hogy valakinek az RX-ét a másik TX-éhez, illetve an- 
nak RX-ét ennek a TX-éhez kössem. RX hallgat tehát 
TX-re, és ha válaszolni szeretne, akkor a hasonló, de másik 
irányú csatornát kell használnia. Itt jön a kérdés, hogy miként 
valósul meg a páros RX-TX összekötés két eszköz között, ha a 
kábel két vége teljesen egyforma? 
Nos, erre azt a megoldást találták ki a szabványkialakítók, 
hogy egyes hálózati eszközök, a számítógépek hálózati kár- 
tyáihoz képest maguktól , fordítanak", azaz sima kábelt hasz- 
nálva jó helyen várják, illetve küldik az adatot. Ilyenek pél- 
dául a HUB-ok, Switch-ek. A hálózati kártyák viszont mind 
egyformán nem fordítanak. Azaz mindben fixen normál sor- 
rendben van az adó és vevő. Így az egyforma kategóriába eső 
eszközöket mindig fordítós kábellel kell összekötni, ha közöt- 
tük kapcsolatot szeretnénk teremteni, mert valakinek minden- 
képpen muszáj elvégeznie azt a feladatot, hogy egy RX min- 
dig TX-el találkozzon, és viszont. 
Az aktív(abb) eszközökön, egy kiemelt , Uplink" porton több- 
nyire van egy átkapcsolási lehetőség is, hogy ne kelljen még- 
sem fordítós (nem egyforma végű) UTP kábelt gyártanunk, ha 
vele egy kategóriába eső eszközzel szeretnénk őt összekap- 
csolni. Sőt, olyan is van már, hogy automatikusan átkapcsol az 
eszköz portja a megfelelő státuszba, ha szükségét érzi. 
Kábelvariációk két témára 
Van tehát kétféle kábel, a sima és a fordítós. Ha képletesen 
egyszerre kézbeveszünk egy ilyen és egy olyan kábelt, akkor 
összesen négy végük van, amiből három vég teljesen egyfor- 
ma. Csupán a fordítós kábel egyik végében fel van cserélve az 
RX a TX-szel. (Ha mindkét végén fordítós végződés lenne, ak- 
kor fordítanánk a fordítást és végül nem történne semmi, csak 
lenne egy szabványtalan , CAT akárhányas" sima kábelünk.) 
Ezek után lássunk szín szerint, hogy mi is a helyes — nem for- 
dítós — sorrend. Az R]J45 nézete szemből, érintkezőkkel felénk 
fordítva (rögzítő-csattintója hátul), balról jobbra: 
A Narancssárgafehér — narancssárga — zöldíehér — kék — 
kékfehér — zöld — barnafehér — barna. 


a A CAT5-ös UTP kábel színsorrendje (ez csak a weben 
színes, az újságban minden kék-ezüst) 








Mint már említettem, csak négy eret használunk a nyolcból, 
ezek az 1-es, 2-es, 3-as és 6-os jelűek, amik színre a 
narancssárgafehér — narancssárga — zöldfehér — zöld, a szab- 
vány szerint. Használhatnánk más színűeket is, de a szabály 
azért szabály, hogy betartsuk. 


Egyébként itt az a fontos, hogy az 1-es és 2-es legyen egymás- 
sal összetekerve, illetve a 3-as és a 6-os szintén. Érdekesség- 
képpen elárulom, hogy a középső kettő — a kékek — a telefon- 
hálózatokban használatosak, ezzel megoldható az is, hogy 
egyetlen UTP kábelen egyszerre utazzon az ügyfél hálózati- 
és telefonforgalma is. Már csak egy RJ45-R]J11 Splitter nevű fil- 
léres kis csatlakozóra van ilyenkor szükség, ami leválasztja a 
kettőt egymásról. Mindezt úgy, hogy egy RJ45-ös és egy RJ11- 
es (vékonyabb, 2-eres) aljzatot ad egyszerre. Egyikből aztán 
megy a számítógép, a másikból meg a telefon: analóg, vagy 
digitális is akár. A barnákról még nem beszéltünk: őket ebben 
a környezetben, pl. az ISDN adta lehetőségek kihasználására 
tartották fenn. Látható, hogy ez az összecsavarás egész jól 
működik, egyáltalán nem zavarják egymást az így egymás 
mellett haladó jelek. 


A fordítós színsorrend pedig a következő: 
A Zöldfehér -— zöld — narancssárgafehér — kék -— kékfehér 
— narancssárga — barnafehér — barna. 





Crossover 

















HD 


A CAT5-ös fordítós UTP kábel színsorrendje 


Szembeötlő, hogy csak a zöldek és a narancssárgák helyzete 
változott, a többiek érintetlenül maradtak. Ezzel megoldottá 
vált a manuális RX-TX párosítás problémája. A szereléshez 
használt RJ45-ös krimpelő fogót bátran kezeljük! Az ábrákon 
látható módon előkészített kábelvégeket egy határozott erős 
mozdulattal szorítsuk meg vele. A kis érintkezők majd átszúr- 
ják az egyes ereket és jó, hibamentes kötést biztosítanak. 


Ha kábelre van szükség, készítsük magunk 


Nem nagy tudomány szépen és pontosan vágni, illeszteni a 
kábelvégeket. Egy kis gyakorlással bárki nekiállhat. Nem kell 
majd ezután egy hirtelen támadt extra igény esetén a szerelők- 
re várni, hogy ők csinálják a fentebb leírtakat. (Azért ötven ká- 
bel elkészítése után már érezni fogjuk, hogy nem is olyan 
könnyű azt a fogót szorítani.) Marad még munka a szerelők- 
nek is bőven, például patch-portok kifejtése, illetve a falban 
futó kábelek elhelyezése, rendezése, stb. 


Füzesi Szabolcs 
fuzesiszEosi.hu 
MCSA 
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A UPnP hálózat segítségével megvalósítható a hálózati eszközök automatikus csatla- 
koztatása és eltávolítása, a műveletek semmilyen emberi beavatkozást nem igényelnek; az összes 
szükséges információt maguk az eszközök hordozzák és hirdetik meg a hálózaton. 


Mit jelent az univerzális Plug and Play? 


A különféle hardvereszközök és az operációs rendszerek Plug 
and Play képességekkel való felruházása jelentősen meg- 
könnyítette a hardvereszközök telepítését és beállítását. Az 
univerzális Plug and Play (UPnP) ezt az egyszerűséget terjesz- 
ti ki a teljes hálózatra, lehetővé téve a hálózati eszközök (há- 
lózati nyomtatók, átjárók, különféle elektronikai eszközök) 
automatikus felderítését és használatba vételét. 

A UPnP több, mint a Plug and Play modell kiterjesztése, segít- 
ségével megvalósítható a beállítást nem igénylő, , láthatatlan" 
hálózat, amely képes a különféle gyártóktól származó külön- 
féle eszközök automatikus érzékelésére és integrálására. 

A UPnP segítségével az eszközök dinamikusan csatlakoznak a 
hálózathoz, meghirdetik képességeiket, és információt gyűjte- 
nek más eszközök jelenlétéről és képességeiről. 

A UPnP képességekkel felruházott hálózat szolgáltatásait a 
legkülönfélébb eszközök vehetik igénybe, felhasználási terü- 
lete pedig igen sokféle lehet, például: 


IA Háztartás-automatizálás 

H Nyomtatás és képfeldolgozás 

TA Audio és videoeszközök 

HA Konyhai gépek 

E Gépjárművek fedélzeti eszközei 


A UPnP a szabványos TCP/IP protokollt használja, így 
könnyen beilleszthető a meglévő hálózatokba. Mivel a UPnP 
nyílt, elosztott hálózati architektúra, amelyet a felhasznált 
protokollok határoznak meg, független lehet bármely adott 
operációs rendszertől, programozási nyelvtől, vagy fizikai mé- 
diumtól (akárcsak az Internet). A UPnP nem definiálja az al- 
kalmazások által használandó API-kat, így az operációs rend- 
szerek gyártói hozhatják létre a megrendelőik igényeinek 
leginkább megfelelő API-t. 

A UPnP eszközöket és szolgáltatásokat (Device and Service 
Descriptions) a Universal Plug and Play Forum definiálja a 
Microsoft által kifejlesztett eszközarchitektúrának megfele- 
lően. A Universal Plug and Play Forum az iparág azon válla- 
lataiból álló csoport, amelyek szerepet kívánnak játszani a 
UPnP eszközök és szolgáltatások kialakításában. A szervezet 
1999. október 18-án alakult, és jelenleg több mint 625 gyártó 
tartozik hozzá. 


A UPnP hálózat komponensei 


A UPnP hálózat három komponens-típust tartalmaz: eszközö- 
ket, szolgáltatásokat és vezérlési pontokat. 
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UPnP eszköz 





Vezérlési pont 
S; 






UPnP eszköz 
Gyökér eszköz 
Beágyazott eszköz 









E UPnP vezérlési pontok, eszközök és szolgáltatások 


A Eszközök - A UPnP eszköz szolgáltatásokból és 
beágyazott eszközökből épül fel. Például egy video- 
magnó szalagtovábbító, TV vevő, óra, stb. szolgáltatá- 
sokból áll, míg a TV/videomagnó kombináció a szol- 
gáltatásokon kívül több együttműködő eszközt is tar- 
talmaz. Az eszközre vonatkozó valamennyi informá- 
ció az eszköz részét képező XML formátumú leírásban 
található meg. Minden eszköz több szolgáltatást is tar- 
talmazhat. 

A Szolgáltatások — A UPnP hálózatban a vezérlés legki- 
sebb egysége a szolgáltatás. Minden szolgáltatáshoz 
műveletek és állapotváltozók tartoznak. Például az óra 
szolgáltatás modellezhető egy állapotváltozó (aktuá- 
lis idő) és két művelet (idő. beállítás, idő lekérdezés) 
felhasználásával. Az eszközök leírásához hasonlóan 
ezek az információk is a UPnP Forum által definiált 
XML formátumú szolgáltatás leírásban találhatók. Min- 
den szolgáltatás állapottáblából, vezérléskiszolgálóból 
és eseménykiszolgálóból áll. Az állapottáblában törté- 
nik a szolgáltatás állapotváltozóinak nyilvántartása. A 
vezérléskiszolgáló fogadja a műveleti kérelmeket (pél- 
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dául idő beállítás), végrehajtja azokat, írissíti az álla- 
pottáblát, és válaszüzeneteket küld. Az eseményki- 
szolgáló a szolgáltatás állapotváltozásairól szóló üze- 
neteket juttat el a megfelelő címzetteknek. 

A Vezérlési pontok — Az UPnP hálózat vezérlési pontja 
képes más eszközök felderítésére és irányítására. A si- 
keres felderítés után a vezérlési pont képes: 

1. Az eszköz, és az általa nyújtott szolgáltatások 
leírásának bekérésére 
2. Az eszköz szólgáltatásaihoz kapcsolódó művele- 
tek kezdeményezésére 
3. A szolgáltatások által küldött eseményüzenetek fo- 
gadására 
A valódi egyenrangú hálózat megvalósításának érdekében 
célszerű, ha az eszközök egyben a vezérlési pont funkciókat 
is tartalmazzák. 


A UPnP protokoll áttekintése 


Hálózati média 

A UPnP hálózat komponenseit bármilyen kommunikációs 
csatornával összekapcsolhatjuk, a média lehet telefonvonal, 
IrDA, Ethernet, IEEE1394 stb. Bármilyen médium, amely alkal- 
mas a hálózati eszközök összekötésére, megfelelő a UPnP há- 
lózat számára is. Az egyetlen megkötés, hogy a médiának biz- 
tosítania kell a szükséges sávszélességet. 

A UPnP nyílt, szabványos protokollokat használ (TCPAP, 
HTTP, XML), képes azonban más technológiákkal (például 
HAVi, CeBus, LonWorks, EIB, X10 stb.) való együttműködés- 
re is UPnP bridge, vagy proxy közbeiktatásával. 


med Speciális eszköz 
termosztát 


Be IP hálózat 








DI ELTSAK ! 
UPnP ébresztőóra 








Bridge-t tartalmazó UPnP hálózat 


Protokollok 


A szabványos protokollok használata biztosítja az egyes gyár- 
tók implementációinak együttműködését. A UPnP által fel- 
használt protokollok igen elterjedtek az Interneten és a lokális 
hálózatokon is, így széles körben megvannak a szükséges is- 
meretek az ezekre alapuló megoldások kifejlesztéséhez és be- 
vezetéséhez. A továbbiakban az UPnP implementálásához 
felhasznált protokollok összefoglaló leírása következik: 


UPnP gyártók által definiált 


UPnP Forum által definiált 


UPnP eszközarchitektúra által definiált 











SDAP 
HITPMU HTTPU HTTPU 
ÍSSDPI (felderítés) ÍGENA ISSDPI ML ZÜLHI Ti E 


leírás 





B Az UPnP protokoll-verem 


A TCP/IP - A UPnP-t alkotó protokollok alapját a TCP/IP 
protokollkészlet képezi. A UPnP eszközök a TCP/IP 
számos protokollját (TCP, UDP, IGMP, ARP, IP) és 
szolgáltatását (DHCP, DNS) használják. 

A HTTP, HTTPU, HTTPMU - A HTTP protokoll és va- 
riánsai szintén alapvető részei a UPnP-nek. A HTTPU 
(unicast) és a HTTPMU (multicast) a HTTP protokoll 
variánsai, amelyek TCP helyett UDP csomagokat 
használnak az üzenetek közvetítésére. A protokollok 
által használt üzenetformátum alapvetően megegye- 
zik a HTTP által használttal. Az ilyen típusú üzenetek 
a multicast kommunikációban, és a megbízhatóságot 
nem igénylő üzenetek közvetítésében játszanak sze- 
repet. 

A SSDP - Az egyszerű szolgáltatás-felderítési protokoll 
(Simple Service Discovery Protocol), mint neve is mu- 
tatja a hálózati szolgáltatások felderítéséért felelős. Az 
SSDP a HTTPU és HTTPMU protokollokra épül, és 
meghatározza a vezérlési pontok által az erőforrások 
megtalálásához szükséges metódusokat. Az SSDP pro- 
tokollt használják továbbá a különféle eszközök, hogy 
jelenlétüket meghirdessék a hálózaton. 


Az UPnP vezérlési pontok aktiválásuk után SSDP keresési ké- 
relmet küldenek szét (HTTPMU protokoll fölött), hogy a háló- 
zaton elérhető eszközöket és szolgáltatásokat felderítsék. A 
vezérlési pont képes keresési kritériumok megadására is, pél- 
dául a keresési kérelem vonatkozhat egy adott eszköztípusra, 
vagy szolgáltatásra. 

A UPnP eszközök a multicast portot figyelik, és keresési kére- 
lem érkezése esetén az eszköz megvizsgálja a keresési krité- 
riumot. Ha az eszköz megfelel a kérelemben szereplő krité- 
riumnak, unicast SSDP (HTTPU felett) választ küld a vezérlési 
pontnak. 

Hasonló módon, ha egy adott eszköz csatlakozik a hálózat- 
hoz, SSDP jelenléti értesítőket küld szét, amelyekben meghir- 
deti az általa nyújtott szolgáltatásokat. 

A GENA - A GENA (Generic Event Notification 
Architecture, általános esemény-értesítési architektú- 
ra) biztosítja a TCP/IP és multicast UDP feletti HTTP 
értesítések küldését és fogadását. A vezérlési pont, 
amely esemény-értesítéseket szeretne kapni egy adott 
szolgáltatás állapotváltozásairól, igénybejelentést 


(subscription reguest) küld az adott eszköz eseményki- 
szolgálójának, amely tartalmazza a szolgáltatás azo- 
nosítását, a saját címét, és azt az időtartamot, ameddig 
az értesítéseket szeretné megkapni. Az értesítések kül- 
désére vonatkozó kérelmet periodikusan meg kell újí- 
tani, illetve a GENA segítségével le is lehet mondani. 

TA SOAP - A SOAP (Simple Object Access Protocol, egy- 
szerű objektum-hozzáférési protokoll) definiálja az 
XML és a HTTP használatát a távoli eljáráshívások 
(RPC) végrehajtásában. A SOAP az Interneten keresz- 
tüli RPC kommunikáció szabványává vált. A UPnP a 
SOAP használatával továbbítja a vezérlőüzeneteket az 
eszközök felé, és a vezérlési pontok ennek segítségé- 
vel kapják vissza a válaszokat és a hibaüzeneteket. 

H XML - Az XML (Extensible Markup Language, kiter- 
jeszthető leírónyelv) a strukturált adatok továbbításá 
nak univerzális webes formátuma. Az XML segítségé- 
vel csaknem bármilyen strukturált adathalmaz egysze- 
rű szövegfájllá alakítható. Az XML-t a UPnP a szolgál- 
tatás-leírások tárolásához, a vezérlési üzenetekhez és 
az eseménykezeléshez használja. 





A UPnP működése 

A UPnP működése az alábbi hat lépésre tagolható: 
Címkiosztás (addressing) 

Felderítés (discovery) 

Leírás (description) 

Vezérlés (control) 

Eseménykezelés (eventing) 

Megjelenítés (presentation) 


BBB BBB 


Címkiosztás (addressing) 


A UPnP hálózat működésének alapja az IP-címek kiosztása. 
Minden eszköz DHCP ügyfélszoftvert tartalmaz, és a hálózat- 
hoz való első csatlakozáskor DHCP kiszolgálótól próbál IP- 
címet kérni. Ha a hálózaton működik DHCP kiszolgáló 
(felügyelt hálózat), az eszköz a megkapott IP-címet fogja hasz- 
nálni. Ha nincs elérhető DHCP kiszolgáló (felügyelet nélküli 
hálózat), az eszköz automatikusan választ magának IP-címet 
(Auto-IP). 


Felderítés (discovery) 


Ha új eszköz csatlakozik a hálózathoz az UPnP felderítési 
protokollja (SSDP) teszi lehetővé, hogy az eszköz meghirdes- 
se az általa biztosított szolgáltatásokat a hálózat vezérlési 
pontjai felé. Csatlakozáskor az eszköz multicast felderítési 
üzeneteket küld szét a hálózaton. Hasonlóan, ha vezérlési 
pont csatlakozik a hálózathoz, az SSDP protokoll használatá- 
val keresi meg azokat az eszközöket, illetve szolgáltatásokat, 
amelyeket vezérelni fog. 

Ha valamely eszközt eltávolítunk a hálózatból, szintén 
multicast üzenetekben közli, hogy beágyazott eszközei és 
szolgáltatásai már nem érhetők el. 
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vezérlési pont 2 szolgáltatás 


vezérlési pont 3 keresés (multicast) 


gyökér eszköz 2 





válaszok (unicast) 


eszköz 





5 Felderítés a UPnP hálózatban 


Leírás (description) 

Miután a vezérlési pont felderített egy adott eszközt, még igen 
kevés információval rendelkezik róla. Csak a felderítési üze- 
netben szereplő információk jutottak el hozzá: 


A az eszköz (vagy szolgáltatás) UPnP típusa 
A az eszköz egyedi azonosítója 
HA URL az eszköz UPnP leírásához 


Hogy a vezérlési pont többet is megtudhasson az eszközről és 
képességeiről, meg kell szereznie a felderítési üzenetben sze- 
replő URL által megcímzett leírást. 


vezérlési pont 3 gyökér eszköz 


€ A gyökér eszköz UPnP leírása 


A szolgáltatás UPnP leírása szolgáltatás 


E A leírások eljuttatása a vezérlési pontokhoz 


Az eszközök UPnP leírása logikailag két részre tagolódik: az 
eszközleírásra, ami a megvalósított logikai vagy fizikai tárolók 
leírása, és a szolgáltatásleírásokra, amelyek az eszköz képes- 
ségeiről tartalmaznak információt. 

A UPnP eszközleírások gyártóspecifikus információkat is tar- 
talmaznak, például az eszköz nevét, szériaszámát, a gyártó 
nevét, weboldalának URL-jét, stb. Az eszköz.által megvalósí- 
tott minden egyes szolgáltatásra vonatkozóan a leírás tartal- 
mazza a szolgáltatás típusát, nevét, valamint URL-t a szolgál- 
tatás leírásához, vezérléséhez és eseménykezelő rendsze- 
réhez. 

Ha az eszközt eltávolítjuk a hálózatból, az multicast felderíté- 
si üzenetek formájában közli a vezérlési pontokkal, hogy 
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ban nem lesznek elérhetőek. 


ús beágyazott eszközei és szolgáltatásai a továbbiak- 


Vezérlés (control) 


Az eszközről és szolgáltatásairól szóló információk 
birtokában a vezérlési pont különféle műveletek elvégzésére 
szólíthatja föl a szolgáltatásokat, és lekérdezheti azok állapot- 
változóinak értékét. A műveletek kezdeményezése távoli eljá- 
ráshívásként fogható fel; a vezérlési pont elküldi a kívánt mű- 
veletre vonatkozó kérést, a művelet befejezése (vagy sikerte- 
lensége) után pedig a szolgáltatás visszaküldi az eredményt, 
illetve a hibaüzeneteket. 


vezérlési pont 


műveleti kérelem 
úg 


eredmény 


változó lekérdezése 


változó értéke 


2 Eszközök vezérlése 


Az eszköz által biztosított szolgáltatás vezérlése úgy történik, 
hogy a vezérlési pont a szolgáltatás leírásában szereplő vezér- 
lési URL-re küldi a megfelelő üzenetet. Az üzenet hatására el- 
végzett művelet megváltoztathatja a szolgáltatás állapotválto- 
zóit, ez eseményt vált ki, amiről az eseménykezelő rendszer 
értesíti a megfelelő vezérlési pontokat. 

A vezérlési pont az állapotváltozók aktuális értékeit is lekér- 
dezheti a szolgáltatástól. A lekérdezés a vezérlési URL-re kül- 
dött megfelelő formátumú lekérdezési üzenet segítségével tör- 
ténhet, amelyre válaszként a szolgáltatás elküldi az állapotvál- 
tozó értékét. 


Eseménykezelés (eventing) 


Miután a vezérlési pont felderítette az eszközt, és lekérte an- 
nak leírását, már képes az eszközzel kapcsolatos események 
kezelésére. Hogy az eseményekről szóló üzeneteket megkap- 
hassa, be kell jelentenie igényét (subscription reguest) a szol- 
gáltatásnak. 


A szolgáltatás az állapotváltozók értékének megváltozásáról 
eseményüzeneteket küld a megfelelő vezérlési pontoknak. Az 
üzenet az állapotváltozók nevét és aktuális értékét tartalmaz- 
za XML formátumban. 

A vezérlési pontoknak bizonyos időközönként meg kell újíta- 
niuk bejelentkezésüket az adott esemény értesítéseire. 

Í gyökér eszköz 


igénybejelentés 








vezérlési pont 1 visszaigazolás 


! megújítási kérelem 
! Í Tamara 
! visszaigazolás 


lemondás 


vezérlési pont 2 


eszköz 





E Eseménykezelés 


Megjelenítés (presentation) 


Ha az eszköz rendelkezik a megjelenítést biztosító URL-lel, a 
vezérlési pont képes az adott oldal letöltésére és böngészőben 
való megjelenítésére. A felhasználó az oldal tulajdonságaitól 
függően vezérelheti az eszközt és/vagy megtekintheti annak 
állapotát. 


Szerényi László 
szerenyi.Iomet.hu 


Meszsáe 
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milyen lehetőségeink vannak a DHCP-szolgáltatás rendelkezésre állásának növelésé- 
re, áttekintjük a beépített monitorozó eszközöket, végül néhány hasznos fogást is- 
mertetünk, amelyek a DHCP-adatbázis karbantartását segíthetik. 


A rendelkezésre állás növelése 


Akik figyelemmel kísérték a tech.net magazin DHCP- 
cikksorozatát, pontosan tudják, hogy a címkiosztó szolgáltatás 
kritikus funkció, s bár nem kell minden másodpercben mű- 
ködnie, a hibás szerver lassan, de biztosan megbénítja az 
egész hálózat életét. Szerencsére számos lehetőség van a ke- 
zünkben, hogy a rendelkezésre állást növeljük. Az alábbi pár 
módszer közül a vékonyabb pénztárcájú és a professzionális 
szolgáltatók is megtalálhatják a nekik megfelelő megoldást. 


Rendelkezésre állás növelése , józan ésszel" 


Szőr mentén már említettük, most újra elővesszük az egyik 
legegyszerűbb és legkézenfekvőbb megoldást, amellyel akár 
napokat is nyerhetünk a DHCP helyreállításához. A címkérés 
módszeréből, valamint az Windowsos ügyfelek alapér- 
telmezett beállításából következik, hogy a szolgáltatást csak 
rövid időre igénylik az IP-címmel dolgozó eszközök. Egy ügy- 
fél akkor kerül kapcsolatba a DHCP-szerverrel, amikor elő- 
ször címet kér, újraindul, amikor meg kell újítani a bérletet a 
bérletidő felénél, sikertelenség esetén a háromnegyedénél, vé- 
gül a bérlet tényleges lejáratakor. A kontaktusok közül csak az 
első és az utolsó kritikus, vagyis ha a kliensnek eleve nem volt 
címe, vagy végleg lejárt a bérlete. Minél hosszabb a két idő- 
pont közötti idő — vagyis a bérletidő, annál nagyobb a valószí- 
nűsége, hogy nem ilyen kritikus helyzet áll fenn. 

Vagyis a bérletidő növelése önmagában a , rendelkezésre ál- 
lást" növelő tényező. Persze csak statisztikai alapon. A bérlet- 
idő függvényét vizsgálva azt tapasztalhatnánk, hogy az ügyfe- 
lek legtöbbje a bérlet egynegyedénél jár. Miért? Mert ha jól 
működik a DHCP-szolgáltatás, akkor a gépek túlnyomó több- 
sége félidőben megújítja a bérletét, vagyis a bérletidő 0 és 
5099-a között egy normális jellegű eloszlás jellemzi a gépek 
címbérleteit. 


Az ügyfelek száma 





t — 
5099 10096 
Az eltelt bérleti idő 
a A ügyfélszámítógépek eloszlása az eltelt bérletidő függ- 
vényében 


tech.net W-bY ETRT 4 Ő WddA 


Tökéletes normális eloszlásról azért nem beszélhetünk, mert 
mindig lesznek olyan gépek, amelyek kikapcsolt állapotban 
vátalusszák" a félidőt, és megjósolhatatlan, hogy mikor ,éb- 
rednek". Ezzel együtt egy kevés gépből (20-60) álló hálózat- 
ban, naponta használt állomásokkal a normális eloszlás na- 
gyon jó közelítés. Belátható, hogy egy 90 napos bérletperió- 
dus esetén majdnem 45 nap áll rendelkezésre a DHCP- 
szolgáltatás megjavításához — megint csak statisztikai alapon. 
Akkor javasolt ehhez a taktikához folyamodni, ha: 


A Egyetlen szerverünk van. 

A Viszonylag kicsi, jól átlátható hálózattal dolgozunk. 

A Stabil a környezetünk, tehát nem konfiguráljuk át 
gyakran a DHCP-kiszolgálót, nem vásárolunk éppen 
most gépeket, nem adunk új IP-cím tartományt a háló- 
zatnak. 

A Nincsenek olyan ügyfeleink, amelyek egy másik háló- 
zatban is rendszeresen megfordulnak, és ott címet igé- 
nyelnek. 

A Nincsenek BOOTP ügyfeleink. (Ők újrainduláskor 
mindenképp igényelnek IP-címet.) 

A Nem konfiguráltuk úgy az ügyfeleket, hogy leálláskor 
engedjék el" a címüket. 


Bár kemény korlátok a fentiek, azért szép számmal akad olyan 
hálózat, amely minden kritériumot teljesít. Fontos megemlíte- 
ni, hogy a több telephely nem akadály, hisz az ügyfél számá- 
ra transzparens, vajon egy valódi címkiszolgáló szervertől 
kapja a címet, vagy egy Relay Agent közvetíti azt. 

Nem ajánlott a megoldás extrapolálása a bérletidő végtelenre 
állításával. Igaz ugyan, hogy ekkor nincs félidő sem, tehát a 
haranggörbe a fenti ábra bal tengelyére ,vasalódik", ám a 
megoldásnak több a hátulütője, mint az előnye. A végtelen 
bérletperiódussal ellátott ügyfél csak akkor reflektál a DHCP- 
opciókban bekövetkezett változásokra ha újraindítják, ám ez 
még csak a kisebbik baj. 

A nagyobb gond, hogy a DHCP-kiszolgáló nem értesül arról, 
ha egy gépet végképp kivonnak a hálózatból. A kiadott cím 
Örökre" az adott MAC-Address-hez tartozik, tehát elvész. A 
cím visszanyeréséhez pontos nyilvántartással kell rendelkez- 
nünk a hálózatunk található valamennyi DHCP ügyfél MAC- 
címéről. Ez túl sok többletmunka a végtelen bérletért cseré- 
be. Igazából épp ezt a nyilvántartást teszi feleslegessé a cím- 
kiosztás. ki 

A fenti módszer, bár működik, igazából a szolgáltatás teher- 
mentesítésével teremt , rendelkezésre állást". Ha a statisztikai 
elv nem fogadható el, vagy nem alkalmazható, egy komo- 
lyabb és megbízhatóbb megoldást kell keresünk. 
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É 7-7 ! —  80-20-as (50-50-es) megoldás 


Ha nem csak egyetlen kiszolgálóval rendelkezünk, 
hanem legalább kettővel, egy ügyes trükkel biztosít- 
hatjuk, hogy az ügyfelek mindig hozzájussanak a 
mindennapi IP-címükhöz. 

A módszer igen egyszerű. Hozzunk létre két DHCP kiszolgá- 
lót, és konfiguráljuk mindegyiken egy-egy azonos címtarto- 
mányra vonatkozó bérlettartomány. Ezután az egyik kiszolgá- 
lón zárjuk ki a címek felső húsz (vagy ötven) százalékát. Vé- 
gezzük el ugyanezt a műveletet a másik szerveren is, de ott az 
alsó 80 (vagy 50) százaléknyi címet zárjuk ki. Az eredményt a 
második ábra mutatja. 


Scope: 172.16.0.1- 
172.16.0.254 


Excluded addresses: 
172.16.0.129-172.16.0.254 [/. 


Scope: 172.16.0.1- 
172.16.0.254 


Excluded addresses: 
172.16.0.1-172.16.0.128 





DHCP Server1 DHCP Server2 






































DHCP kliens DHCP kliens . DHCP kliens DHCP kliens 


E A 80-20-as (50-50-es) eljárás alkalmazása 


A végeredmény két, azonos címtartományt kezelő, de ponto- 
san azonos címeket soha ki nem osztó szerverpár lesz. Az el- 
járás alkalmazásakor a következőre kell figyelni: 


mM Véletlenül sem fordulhat elő, hogy azonos dinamikus 
címet mindkét szerver kiadhasson, tehát a címek kö- 
zött nem lehet átfedés. 

A két scope opcióinak teljesen azonosnak kell lennie, 

beleértve a bérletidőt és a speciális opciókat is. 

A A lefoglalt címeket (reserved addresses) mindkét ki- 

szolgálón be kell állítani, beleértve a kiegészítő opció- 

kat is, ha vannak ilyenek. 

A BOOTP címeket a lefoglalt címekhez hasonlóan kell 

kezelnünk, vagyis kétszer kell felvennünk minden re- 

kordot. 

HA A címtartomány nagyságát úgy érdemes megválaszta- 
ni, hogy akár egy kiszolgáló is képes legyen vala- 
mennyi potenciális ügyfelet kiszolgálni. Ha tehát van 
300 gépünk, és 150-et szolgál ki egy DHCP- 
szolgáltatás, akkor a bérlettartomány tartalmazzon 
legalább 300 címet. Manapság, a privát címtartomá- 
nyok használatakor ez ritkán probléma. (Ugyanakkor 
gyakoribb az 50-5099-os megosztása a bérlettarto- 
mánynak, ezért szerepel ez az ábrán.) 

A Stabil a környezetünk, tehát nem konfiguráljuk át 
gyakran a DHCP-kiszolgálót, nem vásárolunk éppen 
most gépeket, nem adunk új IP-cím tartományt a háló- 
zatnak. 


Nézzük, mit nyerünk a konfigurációval. A módszer valódi 
rendelkezésre-állás növekedést jelent, mert az egyik kiszol- 
gáló kiesése esetén is elláthatók az ügyfelek IP-címekkel. 
Akár kézzel is nekiállhatunk egy teljesen új DHCP kiszolgáló 
felállításának, ha kiesne az egyik, hiszen van egy ,tükörké- 
pünk", amit csak le kell másolnunk. Nem akadályoznak az 
előző megoldásnál felsorolt kritériumok sem, lehetnek ván- 


dorló gépeink, BOOTP klienseink, tetszőlegesen konfigurál- 
hatjuk az ügyfeleket, skálázható megoldáshoz jutunk — amely 
ráadásul mindig működik. Mindezt úgy, hogy nem kellett ext- 
rán konfigurált hardvert vásárolnunk, sem új technológiát be- 
vezetnünk, nincs szükség a Windows Server drágább változa- 
tára. Olyannyira nincs, hogy a ,tükörszerver" akár másik 
operációs rendszert is futtathat, például Linuxot. A feltétel 
csupán annyi, hogy a DHCP-szabvány pontosan kövesse a 
másik rendszer is, legalábbis mindazt tudja, amit mi haszná- 
lunk a szabványból (esetleg: superscope, különleges opciók 
(class, vendor stb.)) 

A magasabb színvonalú szolgáltatásnak azonban ára van. Lé- 
nyegében kétszer kell elvégeznünk minden konfigurációs mű- 
veletet. Ha ritkán változó scope-pal dolgozunk ez kevésbé fáj- 
dalmas, ám ha sok lefoglalt címünk van, netán még BOOTP 
ügyfeleket is kiszolgálunk, akkor nehéz két szerveren precízen 
azonos adatbázist fenntartani. (Ilyenkor javasolt minden mű- 
veletet parancssorból végezni, mert a megkonstruált parancs- 
sort könnyű két szerverre lefuttatni.) 


Katasztrófatűrő megoldás 


Az 50-50-es módszert továbbfejleszthető valódi katasztrófatű- 
rő megoldássá. A következő ábra két telephelyből felépülő há- 


A 


Scopet: 172.16.0.1- 
172.16.0.254 

Excluded addresses: 
172.16.0.129-172.16.0.254 
Scope2: 172.16.1.1- 


172.16.1.254 9 

Exciuded addresses: AraáGA, kt 

172.16.1.129-172.16.1.254 Gaeta aáásádesi 
DHCP Server 172.16.1.1-472.16.1.128 










Scopet: 172.16.0.1- 
172.16.0.254 

Exciuded addresses: 
172.16.0.129-172.16.0.254 


DHCP Server2 




















DHCP Kliens . DHCP kliens 





DHCP kliens 


DHCP kliens 


lózatot mutat az előbb ismertetett DHCP-konfigurációval. 
a Katasztrófatűrő megoldás 


Az eredeti módszert ki kell egészíteni az útválasztók konfigu- 
rálásával (vagy egyéb módon kell biztosítani DHCP Relay 
Agenteket. A rajzról leolvasható, hogy mindkét telephelyen 
mindkét DHCP-szerver megkapja az ügyfelek kérését. Ha 
azonban a továbbító ügynökök némi késéssel indítják el a 
címigénylő csomagokat a távoli hálózat felé, normál műkö- 
déskor a helyi kiszolgáló ,győz". Meghibásodáskor viszont a 
távoli rendszer mindenképp kiszolgálja az ügyfeleket. A mód- 
szer katasztrófatűrő, amennyiben az egyik szerver fizikai meg- 
semmisülése esetén is működőképes marad a címkiosztás. 
Egyéb vonatkozásaiban a megoldás pontosan ugyanazokat az 
előnyöket és hátrányokat hordozza, mint az ,egy telephelyes" 
kialakítás. 


A fürtözés 


A Windows 2000 Advanced Server az első olyan Windows ki- 
szolgáló változat, amely lehetővé teszi, hogy megfelelően 
kialakított hardverrel a DHCP szolgáltatást fürtözhessük. 

A megoldás ezúttal a virtualizálás. A fürtök állomásokból 
(node) és virtuális szerverekből állnak. A virtuális szerverek 
erőforrásokat tartalmaznak. Ilyen erőforrás lehet egy fizikai le- 





mez, egy IP cím, egy hálózati név, vagy éppenséggel egy 
DHCP-szolgáltatás. A fürt elvi működését mutatja a következő 
ábra: 


Felhasználók 





























Node 2 


Node 1 


2 A DHCP-szolgáltatás a virtuális szerveren található 

A kliensek sohasem az egyik, vagy másik állomástól kapják a 
fürtözött szolgáltatást, hanem mindig egy virtuális szervertől. 
Ez a szerver szükség szerint költözhet egyik állomásról a má- 
sikra. (Windows Server 2003 négy, vagy akár 8 node egyiké- 
re.) Az átköltözési idő az erőforrások számától és terheltségé- 
től függ. Ha a DHCP-szolgáltatás számára egy saját virtuális 
szervert definiáltunk, akkor az átköltözés 6-10 másodperc. 
Ennyi tehát a kiesés — tulajdonképpen semennyi. 

A fürtözött DHCP-kiszolgáló, a virtuális erőforrás létrehozását 
leszámítva, semmiben sem különbözik egy ,normális" 
címkiosztó szervertől. A fürt nem ad hozzá és nem vesz el a 
teljesítményből vagy a funkcionalitásból, csupán a rendelke- 
zésre állást növeli. 

A megoldás előnye az előzőekhez képest az egyszeres konfi- 
guráció. Előnyös lehet sok (max: 10000!) scope kezelésekor, 
nagyszámú lefoglalt cím nyilvántartásakor, vagy BOOTP ügy- 
felek kiszolgálása esetén. Akárcsak az előző két módszer, ez 
is valódi rendelkezésre állást növelő eljárás. 

Persze a , tökéletes" megoldásnak ára van: a fürt kialakítása 
host-bus adaptereket, közös háttértárat, speciális HCL listán 
hitelesített konfigurációt feltételez. Az operációs rendszer 
vagy két Windows 2000 Advanced Server, vagy (legalább két) 
Windows 2003 Server Enterprise Edition lesz fürtözéskor. Ez 
jelentős többletköltség, mert a standard változatokhoz képest 
a licencár legalább tízszeres (ha mindkét állomást számolom.) 
Meggondolandó, hogy a fürtök felépítése, működtetése szak- 
értelmet kíván, a hibajavításkor szakértői költségek merülhet- 
nek fel, hacsak nem profik az üzemeltetők. 


Láthatjuk, hogy a rendelkezésre állást segítő technológiák 
igen sokfélék. A különbözőségük lehetőséget teremt arra, 
hogy ötvözzük őket, ha van rá lehetőségünk és a feltételek 
adottak. A fürtözés nem zárja ki a hosszú bérletidő használa- 
tát, ha pedig két fürtünk is futtat DHCP-kiszolgálót különbö- 
ző telephelyen, földrajzilag elosztott megoldást alakíthatunk 
ki az 50-50-es megoldással. Az egyes módszereket építő- 
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elemnek tekinthetjük, és tetszés szerint készíthetünk 
akár nagyon bonyolult címkiosztó architektúrákat is. 
Csupán a fantázia (és a pénz) szab határt az elkép- 
zeléseinknek. Egy fontos tanácsot azonban érdemes 
megfogadni: lehet bonyolult, amit elkészítünk, csak 
legyen jól dokumentált. A rendelkezésre állás egyik halálos 
ellensége a hiányos dokumentáció. A másik a felügyelet hiá- 
nya. 


- 


A DHCP kiszolgálók monitorozása 


A kiszolgálók figyelése a rendszergazdák napi feladatai közé 
tartozik. Ha figyelembe vesszük a DHCP fontosságát, ez még 
inkább így van. Amikor azonban az ember szembesül a telje- 
sítménynapló számaival, hajlamos kissé visszavenni a lendü- 
letből. 
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a A helyi tömegközlekedés menetrendje DHCP számlá- 
lókba csomagolva 


A fenti diagram az egyik nagyobb telephelyünk DHCP- 
kiszolgálójának teljesítményadatait mutatja. A napló eredeti- 
leg a teljes 24 órát rögzítette, én azonban csak az 5.30 és 9.00 
közötti időszakot ábrázoltam. Mivel kezdetben csupa kisimí- 
tott vonalakat láttam, elkezdtem , nagyítani" a diagramot, jól 
látszik, hogy ezer és tízezerszeres ,nagyítás" hozott ered- 
ményt. Végül pusztán az adatok felé fordulva (és tovább szű- 
kítve az időt 5.30 és 8.00 közé) a következőt mondhatjuk a te- 
lephelyről. 
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VVAJK-CORPSERV2 
DHCP Server 
Acks/sec 0,018 
Active gueue Length 0,000 
Conflict Check 0ueue Length 0,000 
Declines/sec 0,000 
Discovers/sec 0,001 
Duplicates Dropped/sec 0,000 
Informs/sec 0,002 
Milliseconds per packet (Avg). 2,000 
Nacks/sec 0,000 
Offers/sec 0,001 
Packets Expired/sec 0,000 
Packets Received/sec 0,020 
Releases/sec 05000 
Reguests/sec 0,016 
E Néhány adat a reggeli indulásról 
E s rá AV ar 1 ? € FK a 1 2 


s. 


7 


fil 





c 
5 


"TIM - fabasdazs pyajlai di 7 


el 





Windows 


A DUCP rejtett szépségei - VII. 


Vannak kimutathatatlanul alacsony értékek, például 
nem alakult ki , sor", hogy a DHCP leellenőrizze ke- 
letkezne-e konfliktus egy cím kiadásakor. Ugyan- 
csak nem történt elutasítás (Nack/sec), ami legin- 
kább azt jelenti, hogy nem érkezett olyan notebook 
a hálózata, amely korábban más alhálózatban kapott címet. A 
címjóváhagyások (Ack/sec) átlagos értéke 0,018 másodper- 
cenként, tehát 1,08 percenként 64,8 óránként. A két és fél óra 
alatt tehát nagyjából 162 gépet kapcsoltak be, amelyek azután 
jóváhagyott címmel elindultak. Persze a többség eleve létező 
bérlettel indult, a discover csomagot is kibocsátó gépek száma 
(0,001x60x60x2,5) mindössze 9. Ha elárulom, hogy kb. 10 
gép állandóan üzemel, 10-et pedig átlagosan nem kapcsolnak 
be, máris megkaptuk, hogy kb. 190 gépet lát el a címkiosztó 
rendszerünk. A DHCP kiszolgáló ,teljes terheltsége" 0,020 
csomag másodpercenként, vagyis csak 1,2 csomag percen- 
ként. Ez a szolgáltatás vélhetően nem fogja megizzasztani a 
legkisebb szervereket sem. 

Tudom, hogy vannak ennél jóval nagyobb implementációk is. 
Egy Internetszolgáltató akár százezer címet is kioszthat egyet- 
len este — nagyvállalati környezetben azonban a DHCP szer- 
ver méretezése és terhelése egyszerűen nem lehet probléma. 


A Diagnostic log 


A mindennapi hibaelhárítás során a teljesítménynaplónál is 
fontosabb lehet a Windows 2000-ben bevezetett diagnostic 
vagy más néven audit log. 

Az audit log használata nem kötelező, a szerver tulajdonságai 
párbeszédpanelen lehet bekapcsolni, az advanced fülön pe- 
dig a naplóállományok helyét is megadhatjuk. 
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General ] DNS ] Advanced] 


B Server 


[7 Automaticaliy update st: 
Hours: Minutes: 


[7 Enable DHCP audit logging 
Writes server activity to a file daily to monitor system performance and 
troubleshoot service issues. 


TT Showthe BOOTP table folder 
Displays the server table which can contain configuration entries to 
support BOOTP clients. 
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5 Egy hasznos szolgáltatás — az audit 


Ápply 


A következő pár sor a fenti szerver naplója ugyanaznap. 








A napló szerkezete meglehetősen egyszerű, táblázatba foglal- 
va a következő: 






Az eseményt azonosító kód 


A bejegyzés dátuma 
A bejegyzés pontos időpontja 








Leírás Az esemény leírása 

. IP-cm Az ügyfél IP-címe 

. Hostnév Az ügyfél host neve a 
MACcím Az ügyfél hálózati kártyájának MAC címe 


A napló elején — angolul — felsorolják a legfontosabb ese- 
ménykódokat. Ilyen lehet az indulás, egy címbérlet kiadása, 
egy cím megújítása stb. Az 50 feletti kódok a szerverek felha- 
talmazásával kapcsolatosak, a DHCP súgójában minden kó- 
dot részletesen leírnak. 

Az audit log hallatlan előnye, hogy minden eseményt felje- 
gyez, ha tehát a címkiosztással, az ügyfelekkel való kommu- 
nikációval vagy a felhatalmazással bármi problémánk lenne, 
ez lesz az első számú segédletünk a probléma elhárításakor. 


tech.net 


Nem részletezzük, csak megemlítjük, hogy a DHCP természe- 
tesen a Windows 2000 eseménynaplójába is képes elhelyez- 
ni bejegyzéseket. Akinek a fenti megoldások egyike sem 
nyújtja azt, amit ő elvár, akkor még mindig adott a lehetőség, 
hogy SNMP alapú megfigyelést végezzen (a DHCP külön MIB 
adatbázissal rendelkezik) vagy akár a Microsoft Operation 
Manager beépített tudástárát is használhatja. A naplózó és 
monitorozó rendszerek további boncolgatása helyett áttérünk 
egy másik nagyon fontos témára, a DHCP adatbázis kezelésé- 
re és karbantartására. 


A DHCP kiszolgálók adatbázisa 


Volt olyan kollégám, aki kétkedését fejezte ki, amikor elmesél- 
tem neki, hogy a DHCP-adatbázisokról akarok írni. Szerinte, 
ha baj van, egyszerűen , csinálunk egy új kiszolgálót" és kész. 
Nos, valóban, az esetek nem elhanyagolható részében ez egy 
járható út. Igaz, előfordulhat esetlegesen címütközés, de ki- 
sebb hálózatoknál ez is ritka. Vannak azonban esetek, amikor 
egy DHCP-adatbázis fontossá válhat. Ha nagyszámú lefoglal 
címünk van, vagy BOOTP ügyfelünk, ha több scope-ot is mű- 
ködtetünk (akár több tucatot), ha különleges paraméterekkel, 
osztályazonosítókkal láttuk el az ügyfeleinket, talán nem 
mindegy, hogy újabb hosszú napokat töltünk el az adatbázi- 
sunk kialakításával, hagyjuk, hogy záporozzon a felhasználók 
panaszáradata a címütközések miatt, vagy némi erőfeszítéssel 
megmentjük az adatbázisunkat az enyészettől. 

A legfontosabb fogásokat tekintjük át: megvizsgáljuk az adat- 
bázis működési elvét, majd néhány kritikus műveletet is is- 
mertetünk, mint például az adatbázis mozgatása, javítása, 
mentése és helyreállítása. 


A DHCP-adatbázis szerkezete 


A DHCP a Microsoft által több termékben is alkalmazott JET 
adatbázismotort használja. (Ez az alapja többek között az 
Access, az Exchange 5.5 és a WINS szolgáltatások.) A hason- 
lóság olyan fokú, hogy aki jártasságot szerzett már egy másik 
termék adatbázisának menedzselésében, könnyedén megbir- 
kózik a DHCP adataival is. 

A JET adatbázis nem egyetlen állományból áll. Ha megvizs- 
gáljuk a DHCP könyvtárat, akkor a következő fájlokat fedez- 
hetjük fel: 


ma ]J50.log (/50xxx.log) — tranzakciós állományok. A JET 
adatbázismotor nem azonnal az adatbázisba írja a vál- 
tozásokat, hanem ún. tranzakciós állományokba. Egy 
tranzakciós állomány mérete állandó, a használat so- 
rán az adatbázismotor csak kitölti. Amikor a fájl meg- 
telt, egy újat kezd a rendszer mindaddig, amíg egy si- 
keres mentés nem történik, vagy szabályosan le nem 
állítjuk a DHCP-szervert. 

A J50.chk - Checkpoint állomány. Annak az információ- 

nak a helyét jelzi az utolsó tranzakciós állományban, 

amelyet sikeresen beírt a rendszer az adatbázisba. 

DHCP.MDB - A tényleges adatbázis. 

Dhcptmp.mdb - Ideiglenes állomány az indexek kar- 

bantartásakor keletkezik. Hibás leálláskor a könyvtár- 

ban maradhat. 

TA Resx.log — Egy ,helyfenntartó" állomány. Ha véletlenül 
elfogyna a hely a DHCP adatbázis kötetén, a motor 
ezeket az állományokat felhasználva fejezné be a 
tranzakciót, majd leállítaná a szolgáltatást. 


BB 
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A teljes adattartalom ezek szerint az adatbázis, a chk 
állomány, valamint az adatbázisba be nem írt 
tranzakciókat tartalmazó állományok együttesével 
írható le. 


Az adatbázis mentése 


Az adatbázis mentéséről maga a rendszer is gondoskodik. A 
regisztrációs adatbázis szerint az alapértelmezett backup út- 
vonal a YoSystemRootYoNSystem32Ydhcptbackup. A mentés 
gyakorisága 60 perc. Ezt az 






értékkel módosíthatjuk. Ugyanitt változtatható meg a mentés 
útvonala. Ha az útvonal más meghajtóra mutat, mint az ere- 
deti adatbázis helye, máris megtettük az első lépést a DHCP 
szerverünk megmentése érdekében. 


Az adatbázis tömörítése és javítása 


A mentésünk megvan, de ez nem jelenti azt, hogy rögtön 
használnunk kellene. Ha az eseménynaplóban piros x-szel 
jelzett JetErr hibákat találunk, a rendszerhez mellékelt 
Jetpack.exe segédprogram segítségével megpróbálkozhatunk 
az adatbázisunk kijavításával. A művelethez le kell állítanunk 
a DHCP kiszolgálót, majd a következő módszert használhat- 
juk: 


1. Navigáljunk a DHCP-adatbázis könyvtárához. 
2. Adjuk ki az alábbi parancsot: 





A művelet megpróbálja orvosolni az adatbázis logikai hibáit, 
továbbá egy offline tömörítést végez. 

(A fenti műveletet fürtözött DHCP-nél is elvégezhetjük, felté- 
ve, hogy előtte az erőforrást Offline állapotba állítottuk. A 
munkakönyvtár ekkor természetesen az erőforrás által hasz- 
nált közös lemezen lesz. A művelet befejezése után az erőfor- 
rást újra el kell indítanunk.) 


Az adatbázis helyreállítása 


Amennyiben nem boldogulunk az adatbázis javításával, kétfé- 
le módszerrel is helyreállíthatjuk a szolgáltatásunkat. 

Az első esetben ragaszkodunk az eredeti adatbázishoz. Ekkor 
a következő teendőink vannak: 


1. Mentsük el a régi — nem használható — adatbázist. 

2. Ha megvan a legutóbbi automatikus mentés, másoljuk 
az eredeti DHCP adatbázis helyére. 

3. Tömörítsük a Jetpack.exe programmal az adatállo- 
mányt. 


Ezután a szolgáltatásnak már el kell tudnia indulni. Ha nem 
találjuk a scope-jainkat, helyre kell állítanunk a DHCP konfi- 
gurációt tartalmazó regisztrációs ágat is. Az automatikus 
backuppal együtt a Windows 2000 ezt is lementi egy 
DHCPCÍg nevű állományba. (Ez valójában a HKLMNSoft- 
ware WicrosoftNDHCPsServerAConfiguration . kulcs tartalma). 
Ha ezzel nem rendelkezünk, a legutóbbi mentésből kell meg- 
szereznünk az állományt. 

Akárhogy is, amikor a szerverünk elindul, egészen biztosan 
nem a legfrissebb állapottal rendelkezünk. Szükségünk lesz a 
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7 regisztrációs kulcs és az adatbázis közötti konzisz- 


tencia megteremtésére, továbbá biztosítani kell, 
més hogy az ügyfelek véletlenül se kapjanak duplán IP 
címet. Az első feladatról úgy gondoskodunk, hogy a 
szerverre jobb oldali egérgombbal kattintunk, majd 
a ,Reconcile" menüpontot választjuk. Ezután be kell kapcsol- 
ni a szerver tulajdonságai közt az Advanced fülön található 
,Conflict detection" eljárást, így a kiszolgáló egy cím kiadása 
előtt - szórt üzenettel — meggyőződik arról, hogy van-e másik 
állomás, amely ezt a címet használja már. Ez persze némi tel- 
jesítmény-visszaeséssel jár. 
Van egy másik járható út a szerver helyreállításához, ennek 
menete a következő: 


1. Egy új adatbázis hozunk létre úgy, hogy elmozgatjuk az 
eredeti adatbázist, és üresen hagyjuk a könyvtárát. A 
DHCP-szolgáltatást elindítva egy új — üres — adatbázis 
keletkezik 

2. Helyreállítjuk a DHCPCfg állomány segítségével a re- 
gisztrációs adatbázis DHCP-szerverre vonatkozó részét 

3. Elvégezzük a ,Reconcile" műveletet. 

4. Bekapcsoljuk a , Conflict detection" eljárást. 


Az adatbázis mozgatása 


A fenti tudásunkat arra is felhasználhatjuk, hogy a DHCP ki- 
szolgálót egyik szerverről a másikra költöztessük. (Tegyük fel, 
hogy a Server1-ről a Server2-re mozgatjuk az adatbázist.) Eh- 
hez a lépések a következők: 


1. Állítsuk le a Server1-en a DHCP szolgáltatást. 

2. Mentsük le a DHCPCfg állományt a regisztációs adat- 
bázis fent ismertetett ágából. Másoljuk az állomány a 
Server2-re. 

3. A Server2-n telepítsük a DHCP szolgáltatást, majd állít- 
suk le a szervizt. 

4. Töröljük a frissen telepített adatbázisfájlokat a 
9osystemroot9otsystem32Ndhcp könyvtárból és másol- 
juk oda a Server! DHCP adatbázisát 


Korábbi 
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5. Állítsuk helyre a DHCPCfg regisztrációs ágat a Server1- 
ről lementett fájl segítségével 

6. Indítsuk el a Server2-n a DHCP-kiszolgálót 

7. Végezzünk , Reconcile" műveletet. 


Zárszó 


A DHCP-t ismertető cikksorozat lezárul. Úgy érzem, hogy az 
elmúlt több mint fél év során egy jó alapos távtanfolyamot si- 
került alkotni. Azt remélem, hogy az olvasók többségének át- 
fogó képet adtam erről a meghúzódó, ámde fontos rendszere- 
lemről. Talán voltak kezdők, akik most már ,majdnem min- 
dent" tudnak, s voltak haladók, akik imitt-amott kiegészíthet- 
ték a tudásukat. Habár az IPv6 hosszabb távon csökkenteni 
fogja témánk fontosságát, úgy gondolom, még hosszú ideig 
hasznos lesz a megszerzett tudás. 

Végezetül egy apró titok: a Windows Server 2003 címkiosztó 
szolgáltatása és a Windows 2000-hez képest minimális vál- 
toztatáson esett át, az itt megszerzett ismerethalmaz tehát jó 
eséllyel 2006-ig, vagyis a következő Windows Server verzióig 
is íriss maradhat. Bár az is igaz, hogy ez esetben kevésbé az 
operációs rendszer, mint inkább a szabványváltozás lehet fon- 
tosabb. Akárhogy is: legyünk résen, legyünk naprakészek. 


Lepenye Tamás, MCSE 2000 
lepenyetomal.hu 


Felhasznált és ajánlott irodalom 
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Iratkozzon fel, így akár e-mailben, akár RSS-formátumban 
eljut Önhöz a legfrissebb tartalom! 


Felhasználói bizalom, mint ei 
a fejlődés kulcsa el 


Az információs társadalom fejlesztésén munkálkodó Magyarországnak szembesülni kell azzal a problémával, 
hogy a fejlődés gátja ma már nem a rendelkezésre álló hardverek szűkössége, és nem is alapvetően a világhá- 
lóhoz való csatlakozás drágasága, hanem egyrészt az Internettel elérhető szolgáltatások kínálatának szűkössége, 


másrészt az a felhasználói bizalmatlanság, amely legfőbb akadálya a szolgáltatások bővülésének. 


A kulcs tehát egy olyan környezet megteremtése, amely az 
információs társadalmi szolgáltatások felhasználóiban bizal- 
mat gerjeszt, amely bővíti a szolgáltatások igénybevevőinek 
körét, és ezzel mintegy spirális kölcsönhatást beindítva az 
elérhető szolgáltatások területén is jelentős fejlődést érünk el. 
A fogyasztóvédelem hagyományos állami és civil fórumai 
fontos szerephez jutnak az online környezetben is, azonban 
a kívánt bizalmi szint megteremtéséhez nem elégséges e 
szervezetek hagyományos fellépése. A fogyasztóvédelem 
csak egy, kétségkívül igen jelentős szegmense az információs 
társadalomnak, azonban itt jóval szélesebb területről van 
szó. A felhasználó csak szűk értelemben véve fogyasztó. Az 
,e" korszak sajátossága leginkább éppen az, hogy a felhasz- 
náló rendszerint szolgáltató is, az aktív szerep egybeolvad a 
passzívval, és így gyarapodik, épül az információtömeget 
egységes virtuális térré szervező Internet. 

Az internet sajátosságából adódóan az állami norma szigorú 
rendelkezései sem elegendőek ahhoz, hogy a kérdést meg- 
nyugtatóan rendezzék. Éppen ezért van szükség egy public 
private partnership jellegű megoldásra, mely az állami szer- 
vek és civil szervek szoros együttműködésén, az önszabályo- 
zás és alternatív vitarendezés eszközrendszerén nyugszik, és 
amely egyik legfontosabb feladatának a tájékoztatást, az in- 
formálást tekinti. 

A világ azon részein, ahol az online kereskedelem, az elekt- 
ronikus kormányzati szolgáltatások, az emberek közötti onli- 
ne kommunikáció különféle formái igen elterjedtek, már 
kialakultak azok a sajátos megoldások is, amelyek a fenti kí- 
vánalmaknak megfelelnek. 

Az Európai Unió hagyományosan igen fontosnak tekintette a 
fogyasztóvédelem erősítését, hiszen ez az egységes belső 
piac bővítésének egyik záloga. Ugyanez a szemlélet az e- 
Europe programokban is megmutatkozik, ahol kiemelt jelen- 
tőséggel szerepel a fogyasztóvédelem kérdése. A dokumentu- 
mokon kívül az európai rangsorolást maga az uniós szervezet 
is tükrözi, hiszen a fogyasztóvédelemnek külön biztosa van, 
és a Bizottság igen szoros együttműködést tart fenn a külön- 
féle fogyasztóvédelmi egyesületek hálózataival. Ugyanakkor 
az Unióban azt is felismerték, hogy az információs társada- 
lomban a jelen cikk elején kifejtettek értelmében más jellegű 
probléma kezelésre is szükség van, így több példamutató 
speciális intézményt is létrehoztak erre a célra. 

Az Információs Társadalom Bizottság sajátos kezdeményezé- 
se a Dr. eCommerce. A sajátos szolgáltatás célja a fogyasztók 
tájékoztatása, a felvilágosítás. A hozzá intézett kérdéseket 
megválaszolja, és a kérdéseket (az azokat feltevő személy 


azonosítása nélkül), valamint a válaszokat nyilvánosan meg- 
jelenteti. Dr. eCommerce 1999. óta működik. A hozzá inté- 
zett kérdések variációja igen széles, az elektronikus fizetési 
módok jogi helyzetétől az Internet és a magánszféra védel- 
mének viszonyát firtató kérdésen át az EU elektronikus keres- 
kedelemre irányuló marketingjén keresztül minden, amely az 
Internettel, és az információs társadalmi technológiákkal kap- 
csolatos, már napirendre került. 

Az EEJ-NET (European Extra Judicial Network) szolgáltatásai 
már jóval túlmutatnak a felvilágosításon és tanácsadáson. Ez 
a szervezet már nem csak a fogyasztók, hanem a felhaszná- 
lók szélesebb köre érdekében tevékenykedik, és egyfajta 
adatbázisaként szolgál az elérhető gyors, bíróságon kívüli (al- 
ternatív) vitarendezési megoldásoknak. 

A CECUA (Confederation of European Computer User 
Association — Európai Számítógép Felhasználók Szövetsége) 
12 Európai Uniós illetve EEA és EFTA tagállam területén véd 
több mint fél millió felhasználót, aki tagjai a nemzeti szerve- 
zeteknek. 1982-ben alapították, és azóta szorosan együttmű- 
ködik az Európai Bizottsággal, és így a CECUA az egyik meg- 
határozó társaság a felhasználók érdekeinek védelmére vala- 
mint az információs társadalom előmozdítására. E független 
szervezet nevéhez kötődik az Internetre kidolgozott , Bill of 
Rights" kidolgozása is. 

A civil és állami együttműködésen alapuló megoldások terü- 
letén a tagállamokban is érdekes és igen jól működő példá- 
kat találhatunk. Így Svédországban négy magánszemély 
1999-ben megalakította az Internet Ombudsman intézmé- 
nyét kifejezetten azzal a céllal, hogy a felhasználók számára 
nyújtsanak segítséget. A non-profit szervezet a felhasználók 
részére nyújt ingyenes tanácsadást, bármely az Internet hasz- 
nálatához kapcsolódó kérdésben, technikai, jogi vagy etikai 
jellegű kérdések esetén. Működését anyagilag egyrészt a svéd 
Kormány Kereskedelmi Minisztériuma (Government Trade 
Department), a svéd Királyi Bíróság és a svéd parlament által 
alapított KK-alapítvány (The Knowledge Foundation — Tudás 
Alapítvány) támogatja. 

Nem kell azonban ilyen messzire mennünk, hiszen a Lajtán 
túl, a szomszédos Ausztriában az ÖIAT (Austrian Institute for 
Applied  Telecommunication), és a VKI (Consumer 
Information Association) — amely Ausztria fő fogyasztóvédel- 
mi szervezete — közösen létrehozta és működteti az Internet 
Ombudsman intézményét. 

Az Internet Ombudsman munkáját az Osztrák Szövetségi 
Munkaügyi Kamara, a Szövetségi Igazságügyi Minisztérium, 
a Gazdasági és Munkaügyi Szövetségi Minisztérium, az 
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Internet Szolgáltatók Tanácsa, az Osztrák Fogyasz- 
tói Tájékoztató Szervezet és az Osztrák Szövetségi 
Kereskedelmi Kamara támogatja anyagi és más esz- 
közökkel. 

Az Ombudsman szerepe elsősorban az elektronikus 
kereskedelem fejlesztéséhez kötődik, így feladata az 
Interneten való vásárlás új aspektusáról általános információ- 
kat adni, fő célja az e-kereskedelem biztonságát növelni a 
széleskörű tájékoztatással, és a biztonsági alapkövetelmény- 
nek meghatározásával. Konkrét problémák felmerülése ese- 
tére emellett gyors, alternatív vitarendezési eljárásokat kí- 
nálnak. 

Működésének hatékonyságát és elismertségét bizonyítja, 
hogy 2000-ben a Gazdasági és Munkaügyi Minisztérium ál- 
tal alapított PR díjat az Internet Ombudsmannak ítélték oda. 
Talán zavaró, hogy az említett intézmények visszaköszönő 
megnevezése az ombudsman. A kifejezés a magyar olvasó 
számára nyilván zavaró, amikor az országgyűlési biztosok in- 
tézményére gondol. Ugyanakkor az ombudsman lényegében 
egy közbenjáró, szószóló, többnyire vitarendező fórum, 
amely a világ számos országában, így elsősorban az angol- 
szász nyelvterületeken civil kezdeményezésre áll fel és mű- 
ködik. 

A felhasználók védelmének társadalmi keretekben történő 
megoldása azért alkalmasabb a bizalom megteremtésére, 
mint a szigorú normatív megközelítés és az állami szervek 
hatáskörébe utalás, mert ha a szolgáltatók csak szankciók ál- 
tal kényszerülnek a magas fokú bizalmat kiérdemlő minőség 
biztosítására, az információs társadalom világában az állam- 
határokat nem ismerő virtuális térben az előírásokra könnyen 
fittyet hánynak. Ám ha az érdekük azt diktálja, hogy önként 
feladva szuverenitásuk egy részét, meghatározott önszabá- 
lyozó csoportba tömörülve annak szabályait magukra nézve 
kötelezőnek fogadják el, azt az állami végrehajtás fenyegető 
veszélye nélkül is betartják. 

Jó példa erre a TRUSTe. Megalakításának ötlete 1996-ban 
pattant ki egy számítástechnikai konferencián, ahol éppen a 
magánszféra védelmének lehetőségein töprengtek egyesek. A 
TRUSTEe - ahogy önmagát hirdeti — eszköz az önszabályozás- 
hoz: nonprofit alapon, önkéntesen létrehozott és globálisan 
működő, mind az államoktól, mind az ipari szereplőktől füg- 
getlen kezdeményezés. 

A TRUSTEe olyan mechanizmust alakított ki, amely a közbizal- 
mat növeli a fogyasztókban a web site-ok iránt. Ha az adott 
site megfelel a TRUSTe szabta feltételeknek, akkor ennek iga- 
zolásául jogosult a megfelelő vizuális jel elhelyezésére. A jel- 
legzetes embléma bizonyítja, hogy olyan oldalon jár a fel- 
használó, ahol személyes adatait a legnagyobb gondossággal 
kezelik. 

Arra az esetre, ha a felhasználó ennek ellenére a TRUSTe 
emblémával ellátott web site-on személyes adatainak jogosu- 
latlan felhasználásával találkozik, megfelelő alternatív vita- 
rendezési eljárást is felkínálnak, a házőrző kutya után elneve- 
zett ún. , Watchdog Dispute Resolution" megoldást. 

Az eljárás a szabályok szerint ingyenes, és nyitva áll minden 
magánszemély számára, aki úgy véli, hogy a TRUSTe emblé- 
ma alatt működő szolgáltató személyes szférájában megsér- 
tette. A vita kérelemre indul, az eljárás online zajlik. Ha a pa- 


naszos ügyben eljáró , bíró" a kérelmet megalapozottnak ta- 
lálja, kötelezheti az érintett szolgáltatót, hogy módosítsa a 
feltüntetett adatokat, vagy törölje közülük azokat, amelyek 
más jogát sértik; módosítsa az adatkezelési szabályzatát; illet- 
ve más szükséges intézkedéseket megtegyen. 

Sor kerülhet továbbá az illetékes állami felügyeleti szerv érte- 
sítésére, vagy a TRUSTe embléma eltávolítására, és a szolgál- 
tató és a TRUSTe közötti szerződés felbontására is. Az első fo- 
kú döntéssel szemben a TRUSTe fellebbezési fórumához le- 
het fordulni, az eljárás tehát két fokon zajlik. 

A szabályok betartása tehát önkéntes ugyan, de ki is kénysze- 
ríthető az alternatív eljárással. Az eljárás során alkalmazható 
legsúlyosabb szankció a TRUSTe szerződés felbontása, vagyis 
a csoport tagjai közül történő kizárás. Ez azért jelenthet ko- 
moly hátrányt az Internetes kereskedőnek, mert a bizalmat 
hozó embléma elvesztése az üzletmenetére is hátrányos le- 
het. Az önkéntes alávetést biztosító érdek tehát a TRUSTe vo- 
natkozásában is tetten érhető. 

Magyarországon is tapasztalhatók már előrelépések e kérdés- 
ben. Az október 1-én kihirdetett kormányrendelet, amely az 
informatikai és hírközlési miniszter hatás- és feladatkörét ha- 
tározza meg, előírja, hogy a miniszter — a felhasználói és 
szolgáltatói érdekképviseleti szervek útján — online ügyfél- 
szolgálatot üzemeltessen. Az Országgyűlés előtt folyamatban 
lévő, az elektronikus kereskedelmi szolgáltatásokról szóló 
2001. évi CVIII. Törvény módosításával Magyarországon elő- 
ször az állami norma szintjén kerül elismerésre az önszabá- 
lyozás, mint az azzal egyenrangú, ahelyett egyes esetekben 
hatékonyabb szabályrendszer, valamint az alternatív vitaren- 
dezési eljárás, amely megfelelő forma lehet az információs 
társadalom gyors választ igénylő problémáira. 

Az ugyancsak a t. Ház előtt lévő elektronikus hírközlési tör- 
vénybe is beépült egy intézmény, a Hírközlési Fogyasztói Jo- 
gok Képviselője. A jogalkotó kétségtelenül előremutató szán- 
dékát reprezentáló megoldás legnagyobb hibája az, hogy az 
irodavezetői beosztást kapó köztisztviselő és irodája lényegé- 
ben nem rendelkeznek majd bővebb jogosítványokkal, mint 
amelyek bármely civil szervezetet megilletnek, ezért az in- 
tézmény igen sok kritikát kapott már eddig is. 

A most készülő Magyar Információs Társadalmi Stratégiában 
is kiemelt kérdésként jelenik meg a bizalom és biztonság kér- 
dése, olyannyira, hogy a készülő programfüzetek közül az 
egyik e kérdésnek lett szentelve. 

Az Informatikai Érdekegyeztető Fórum, mint a magyar infor- 
mációs társadalom szolgáltatóinak és felhasználónak teljes- 
ségét reprezentáló legnagyobb szervezet, már 2002. nyarán 
javasolt az előbbiekben kifejtetteknek megfelelő érdekvédel- 
mi szolgáltatás felállítását. A társadalmi és állami együttmű- 
ködést reprezentáló public private partnership megvalósítá- 
sának előkészületei végre megkezdődtek, és várható, hogy 
2004-ben Magyarország élenjáró példával járhat a csatlako- 
zó országok számára is a felhasználók érdekeinek védelmére 
kifejlesztett megoldással, amely számottevően járul majd 
hozzá az oly fontos bizalom megteremtéséhez. 


Dr. Mayer Erika 





Tanúsítványkiadók a 


Mindowsban 


Oualified Subordination 


Sorozatunk utolsó része az altanúsítványkiadókról szól. 


A kiadható tanúsítványok névterének meghatározása 


Az altanúsítványkiadók működési köre korlátozásának követ- 
kező lépése az lehet, hogy meghatározzuk, KI kérhet és kap- 
hat tanúsítványt az adott tanúsítványkiadótól. Ehhez különfé- 
le korlátozó szabályokat (angolul , constraint"-eket) definiá- 
lunk. Elsőként ismerkedjünk meg a lehetséges szabályokkal! 


Az igénylő , nevének" korlátozása (Name Constraints) 


A címben szereplő ,név" nem biztos, hogy egyértelműen utal 
a Name Constraintek szerepére. Ezek a szabályok arra valók, 
hogy az igénylő Active Directory-beli vagy DNS neve, URI-ja, 
e-mail címe vagy IP-címe alapján korlátozhatjuk a CA-hoz va- 
ló hozzáférést. Ennek megfelelően többfajta Name Constraint 
létezik, amelyeket néhány sor múlva egyenként bemutatunk. 
Fontos, hogy ha a tanúsítványkiszolgálón definiáltunk Name 
Constraintet, a beérkező tanúsítványkérésben szereplő nevek 
mindegyikének engedélyezve kell lennie, különben a CA a 
kérést visszautasítja. 

Létrehozhatunk engedélyező és tiltó típusú Name 
Constrainteket is. A tiltó szabályok minden esetben nagyobb 
erejűek, mint az engedélyezők, tehát ha a tanúsítványkérés 
olyan nevet tartalmaz, amelyre mind engedélyező, mind pe- 
dig tiltó szabályt létrehoztunk, a kérést el kell utasítani. Alap- 
értelmezésben szabály az is, hogy ha szabályok között egy 
adott típusú (LDAP, DNS, stb.) névre vonatkozó tag — akár en- 
gedélyező, akár tiltó típusú — szerepel, a tanúsítványkérésben 
is kell, hogy legyen egy megfelelő típusú név. Ha nincs, — füg- 
getlenül attól, hogy tiltás esetleg nem vonatkozik rá, — a tanú- 
sítvány nem adható ki. 

A Name Constraintek kiértékelésénél figyelembe kell venni a 
tanúsítványt igénylő nevét (Subject mező), valamint az összes 
létező alternatív nevet is (Subject Alternative Name bővít- 
mény). 

Lássuk most a Name Constraintek típusait: 


1. Relative Distinguished Name Constraint 


RDN Constraintben az objektum Active Directory-beli LDAP 
nevét adhatjuk meg (pl. ,CN-Computers, DC-falatrax, 
DC-hu"), a következő formátumban: 





(DIRECTORYNAME - "CN-Computers, DC-falatrax, 1 
A fenti példa a falatrax.hu tartomány minden olyan számító- 
gépére utal, amelyek a Computers tárolóban vannak. Ha tehát 
az  RDN Constraint egy objektumokat tartalmazó 
címtárobjektumra (azaz, ,konténerre") utal, a szabály az ob- 
jektum minden gyermekére vonatkozik. 





DIRECTORYNAME -— "oUuzKönyvelés, DC-falatrax, DC-hu" 


DIRECTORYNAME - "CN-Gizike, 
DC-falatrax, DC-hu" 


0U-Recepció, 


Az első példa tehát a Könyvelés szervezeti egység minden tag- 
jára (felhasználókra és számítógépekre egyaránt), a második 
példa pedig kifejezetten a recepciós Gizikére vonatkozik. 


2. DNS Name Constraint 


A DNS Name Constraint az igénylő (ezesetben nyilván számí- 
tógép vagy hálózati eszköz) DNS nevére utal. Itt is meghatá- 
rozhatunk konkrét nevet, de hozhatunk szabályt egy DNS zó- 
na minden tagjára is. Példák: 

DNS - falatrax.hu 1 53 

A falatrax.hu DNS zóna minden tagja (például a 
www.falatrax.hu, de önmagában a falatrax.hu is) 


DNS - .falatrax.hu 


A falatrax.hu DNS zóna gyermekei (Figyeljünk a pontra!) 
Ilyen a www.falatrax.hu, de NEM ilyen maga a falatrax.hu. 


DNS - szerver.falatrax.hu. 


A szerver.falatrax.hu (és gyermekei, ha vannak, pl.: 
www.szerver.falatrax.hu). 


Uniform Resource Identifier (UR!) Constraint 


Az URI egy szöveges azonosító, amely tartalmazza egy háló- 
zati erőforrás pontos elérési útját, beleértve az eléséhez szük- 
séges protokollt is, a következő formátumban: 
zprotokoll5://cszerver DNS név5[:cport: ]/dfájl elérési út: 
Ilyen URI például egy URL is: 
http://vwww.falatrax.hu/default.htm, ahol a protokoll a http, a 
szervernév a www.falatrax.hu, a fájl elérési útja pedig 
/default.htm. Protokoll lehet még például az ftp, telnet, mailto, 
gopher, stb. URI Constraintek segítségével tipikusan 
webkiszolgáló-tanúsítványkéréseket engedélyezhetünk, illet- 
ve tilthatunk, az alábbi formátumban: 





E-mail, UPN Constraint 

E-mail, illetve UPN (User Principal Name) Constraint segítsé- 
gével az igénylő e-mail címére, illetve Active Directory-beli 
UPN nevére hivatkozhatunk. A kettő között technikailag az a 
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különbség, hogy az UPN nevet UTF-8 kódolással 
kezeljük, míg az E-mail ellenőrzésénél a tanúsít- 
ványkezelésnél szokásos (IA5) karakterkódolást 
használ a CA (ez nem tartalmaz ékezetes karaktere- 
ket, így az ellenőrzés is ékezetfüggetlen lesz). 


Formátuma: 





illetve 





Az e-mail példák közül az első a már ismert Gizikére, a má- 
sodik a falatrax.hu tartomány minden felhasználójára vonat- 
kozik. UPN neveket mindig kettesével kell létrehoznunk: egy- 
szer a szokásos módon, egyszer pedig úgy, hogy a € karaktert 
ponttal helyettesítjük. 


IP Address Constraint 


Az IP Address Constraint a tanúsítványt igénylő ügyfél IP címe 
alapján segít eldönteni, hogy a tanúsítvány kiadható-e. A 
Constraintben meg kell adnunk az alhálózat, illetve az ügyfél 
IP címét, majd / jel után az alhálózati maszkot. Ha a maszk 
255.255.255.255, a Constraint konkrét IP címre, különben az 
adott alhálózatra vonatkozik: 





A Name Constraint használata 


Name Constrainteket altanúsítványkiadó telepítése esetén a 
CAPolicy.inf, ,idegen" tanúsítványkiadó beléptetése (azaz a 
konkrét értelemben vett gualified subordination) esetén pedig 
a tanúsítványkérés előállításához használt policy.inf fájlban 
kell megadnunk, a következő módon: 





A fenti példa esetén a tanúsítványkiadó a falatrax.hu Active 
Directory-tartomány felhasználóinak (kivéve a külsősök szer- 
vezeti egység tagjait) adna tanúsítványt, amennyiben a kérés- 
ben található e-mail cím a Ofalatrax.hu tartományba esik. Ha 
a tanúsítványkérés nem tartalmaz e-mail címet vagy UPN hi- 
vatkozást, a jogosultság nem ellenőrizhető, ezért a CA 
visszautasítja azt. 


Az igénylő nevének korlátozása a gyakorlatban 


Itt az ideje, hogy készpénzre váltsuk a tudásunkat. A példában 
a falatrax2003.hu tartományban, a Falatrax Enterprise Root 
CA tanúsítványkiadó ,alá" beléptetjük a Falatrax Issuer CA-t, 
amely csak a tartomány Kőművesek szervezeti egységének 
tagjai részére ad ki tanúsítványt, persze csak akkor, ha a kérés- 
ben a megfelelő e-mail cím (felhasználónévé-oPbkomuve- 
sek.falatrax2003.hu) szerepel. A példa kedvéért a 


Eburkolok.falatrax2003.hu e-mail címeket explicit megtiltjuk. 





Most is az előző részben létrehozott új tanúsítványsablont 
használjuk (hiszen a ,gyári", 1.0-s verzió nem alkalmas a 
Oualified  Subordination-re). Ha kitöltöttük a CAPolicy.inf 
fájlt, a Certification Authorities konzolban kérjünk új tanúsít- 
ványt a gyermek CA-nak (AI tasks 2 Renew CA 
Certificate. ..). A tanúsítványkérést most se hagyjuk elküldeni 
(mert az MMC-s varázsló nem venné figyelembe a Name 
Constraints mezőket), hanem mentsük el fájlba. A kérést tar- 
talmazó .reg fájlt pedig ,oltsuk" be a CAPolicy.inf-fel, majd ne 
felejtsük el digitálisan aláírni se! Adjuk ki a következő paran- 
csot: . 





Ezután válasszuk ki az előbb elmentett .reg fájlt, majd a 
CAPolicy.inf-et, a digitális aláírás tanúsítványát (a Oualified 
Subordination Reguest típusú aláírótanúsítvánnyal), az ered- 
ménykérnt keletkezett kérést pedig mentsük el új néven (ez is 
egy .reg fájl lesz). Ezt a .reg fájlt kell eljuttatnunk a vállalati 
gyökér CA-hoz, a webes felületen, vagy egy újabb paranccsal: 





A parancs kiadása után válasszuk ki a gyökérkiszolgálót, majd 
adjuk meg a fájlnevet, amibe a kész tanúsítványt mentheti az 
eszköz (.cer)! Ezután már csak be kell importálnunk a gyer- 
mek CA-ba a kész tanúsítványt (Certification Authorities kon- 
Zol, All Tasks 2 Import CA Certificate. ..), és már készen is va- 
gyunk. 


tech.net 


fd P.3) 





General  Details ] certification Path ] 


Show: [calls 2 
Value 


ERNNN . st e zznselJNSÉ ss sése Ös 
FH CRL Oistribution Points [1]CRL Oistribution Point: Distributic 
Fáauthority Information Access [1]Jáuthority Info Access: Access Mi 
E Basic Constraints Subject Type-CA, Path Length Cor 





















shal 
€285 4d5f 67 b0 a4 7a ef a2 3adi 
Revocation Status : OK, Effective Ce 





KR] Thumbprint 
FSJExtended Error Information 


(2]Subtrees (0..Max): 

RFC822 Namezőkomuvesek. falatrax2003.hu 
(3)sSubtrees (0, Max): 

DNS Namez 
([ajsubtrees (0, Max): 

Directory Address: 


OUzkomuvesek 
DCsfalatrax2003 
DCzhu 





B A kész CA tanúsítvány, és benne a Name Constraints 
szabályaink 


Amint látható, ha a policy-ben egy-egy Name Constraints tí- 
pust nem definiálunk, az üres értékkel kerül bele a tanúsít- 
ványba. Ez a joker, azt jelenti, hogy az adott típusú név bármi 
lehet (esetünkben ilyen pl. a DNS Name is). 


Tanúsítványkérés a gyermekkiadótól 


Próbáljuk ki, működnek-e a korlátozások. Kérjünk tanúsít- 
ványt egy felhasználóval, akinek az e-mail címe megfelelő 
ugyan (tesztekomuvesek. falatrax2003.hu), de nem a megfele- 
lő Active Directory szervezeti egységbe tartozik! A felhaszná- 
ló tanúsítványkérésére hibaüzenet a válasz: 


Certificate Reguest Wizard, 


€9 The certification authority denied the reguest. The certíficate has an invalid name. The 


name is not included in the permitted list or is explicitly excluded. 





B ,Arkérést a tanúsítványkiadó elutasította. A tanúsítvány 
érvénytelen nevet tartalmaz. A név nem található az 
engedélyezettek között, vagy kifejezetten tiltva van" 


A felhasználónak ennyi talán elég is. Ha pontosan tudni sze- 
retnénk, hogy mi a probléma, nézzük meg a kérést a 
Certification Authority MMC konzolban: 


[ETET ta ME 


Ele Action Wew Help 
alan BBI? 
[DJ certfication Authortty (Local) 
— [EJ Falatrax Enterprise Issuer CA. [Error Constructing or Pubkshing Certficate No Permitted Name Constrant for 
( Revoked Certficates 
J Issued Certíficates 
(I Pending Reguests 
I Falled Regyests 
JI Certíficate Templates 








a Az elutasított tanúsítványok listájában látszik az indok- 
lás is 





A Failed Reguests listában keressük meg a tanúsít- 
ványkérést. Itt a Reguest Status Code oszlopban 
ugyanazt az üzenetet látjuk, mint a felhasználó; a 
Reguest Disposition Message viszont már bővebb 
információkkal szolgál: 


Error Constructing or Publishing Certificate. No Permitted 
Name Constraint for cDirectory Address: 
E-tesztekomuvesek.falatrax2003.hu, CN - Teszt 

Elek, CN - Users, DC - falatrax2003, DC -— huz. 


Helyezzük át most a felhasználót a ,Komuvesek" szervezeti 
egységbe, és tegyünk újabb próbát! A kérés ezúttal már sike- 
res lesz. 


Két, egymástól független CA hierarchia összekapcsolása 


A következő eset az, amikor a gualified subordination célja 
két, egymástól független tanúsítványkiadó hierarchia össze- 
kapcsolása (cross-certification, azaz keresztbehitelesítés). En- 
nek több formája van: összekapcsolhatjuk a két hierarchia 
csúcsát, gyökér-tanúsítványkiadóit, kapcsolatot hozhatunk lét- 
re az egyik hierarchia gyökere és a másik hierarchia egyik 
gyermek CA-ja, vagy akár a két hierarchia gyermek CA-i kö- 
zött is. 





82? 
4 A kereszttanúsítás lényege 


A lényeg minden esetben az, hogy a , saját" felhasználóink el- 
fogadnak bizonyos célokra alkalmas, az ,idegen" hierarchia 
CA-iból származó tanúsítványokat, anélkül, hogy ehhez az 
idegen gyökér CA-t fel kellene vennünk a megbízott gyökér- 
tanúsítványkiadóink (Trusted Root Certification Authorities) 
listájába. 


Vegyünk egy példát! A fenti ábrán két, egymástól független ta- 
núsítványkiadó-hierarchia látható (CA 1a-3a illetve CA 1b- 
3b). Tegyük fel, hogy az ,a" hierarchia felhasználója digitáli- 
san aláírt levelet kap a ,b" hierarchia egyik felhasználójától. 
Az aláíráshoz használt tanúsítvány a CA 3b tanúsítványkiadó- 
tól származik. A tanúsítvány ellenőrzése (a tanúsítványlánc 
felépítése) során a vastag fekete nyilak mentén eljutunk a ,b" 
hierarchia csúcsáig, a CA 1b gyökér-tanúsítványkiadóig. Nor- 
mális esetben az ellenőrzés itt véget ér, és mivel a CA 1b nem 
szerepel a felhasználónk megbízott gyökér CA-inak listájában, 
a tanúsítvány érvénytelen lenne. 
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A keresztbetanúsításnak köszönhetően a két hierar- 
chia gyökér CA-i egymás minősített ,gyermekeinek" 
számítanak (ezt jelzi az ábra tetején látható kettős 
fekvő nyi). Az ellenőrzés ezért a CA gualified 
subordination tanúsítványa mentén folytatódik — a 
CA 1b kereszttanúsítványát viszont a CA Ta adta ki, aki nem 
más, mint a felhasználónk saját gyökér CA-ja! 

A valóságban gyökér CA-k között ritkán hoznak létre kereszt- 
tanúsítást, de az ábra alapján könnyű belegondolni a tanúsít- 
ványlánc felépítésébe akkor is, ha a kereszttanúsítás egy gyer- 
mek és egy gyökér, vagy akár két gyermek CA között áll fenn. 
Issuance és Application Policies 

A tanúsítványok mezőinek bemutatása során szerepelt két 
speciális, a tanúsítvány kezelésére, használatára utaló mező: 


TA Issuance Policy: meghatározza, hogy az adott tanúsít- 
vány kiadása során milyen biztonsági előírásoknak 
megfelelően kell eljárnunk (a különböző eljárásoknak 
saját OID-jük van, de generálhatunk saját eljárást is) 

TA Application Policy: meghatározza, hogy az adott tanú- 
sítvány milyen célra használható fel (minden felhasz- 
nálási területnek saját OID-je van, és természetesen itt 
is generálhatunk saját felhasználási területet, saját 
OID-vel) 


A Oualified Subordination tanúsítvány kiadása (egészen pon- 
tosan kérése) során a nevek korlátozása mellett a fenti két 
policy is megadható, így elérhetjük, hogy egy 
altanúsítványkiadó (vagy egy keresztbehitelesített CA hierar- 
chia) például csak titkosított e-mail küldésére alkalmas tanú- 
sítványokat adhat ki (illetve csak azokat tekintjük érvényes- 
nek). 


Az Issuance Policy meghatározása 


Amikor a Oualified Subordination során a ,gyermek" CA-nak 
új tanúsítványt kérünk, - mint eddig is — egy .inf fájl határoz- 
za meg a tanúsítvány különféle jellemzőit. A továbbiakban ezt 
a fájlt policy.inf-nek nevezzük, de a fájl neve tulajdonképpen 
nem lényeges, csak az, hogy a tanúsítványkérés generálása s0- 
rán a megfelelő fájlt adjuk meg (ugyanúgy, mint néhány be- 
kezdéssel korábban, a Name Constraints definiálása esetén). 
Ha tehát egy tanúsítványkérésben korlátozni szeretnénk a 
használható Issuance Policy-k értékeit, a következő sorokat 
kell elhelyeznünk a policy.inf fájlban: 





Emlékezzünk, hogy az Issuance Policy értékek minden Active 
Directory-ban mások és mások, mert véletlenszerűen generált 
értéket tartalmaznak. Ha olyan CA hierarchiákat akarunk 


összekapcsolni, amelyek különböző tartományban működ- 
nek, a különböző OID-ket egymás mellé kell rendelnünk, ezt 
nevezik Policy Mapping-nek. Innen tudja majd az egyik CA, 
hogy mit jelent egy adott Issuance Policy a másik CA-ban: 





A [PolicyMappingsExtension] részben soronként egy-egy 
OID-rendelünk össze. Előre kerül a saját OID-nk (az, ami a 
[PolicyStatementExtension] szakaszban is szerepel) majd 
egyenlőségjel után a partner CA hierarchia értékei. 


Unexpected Trust 


Azaz váratlan bizalom". Tegyük fel, hogy ualified 
Subordination-t hozunk létre a partnervállalatunk egy adott 
gyermek CA-jával. Elfogadjuk az általa kiadott tanúsítványo- 
kat, mert megbízunk benne. Ha azonban ez a tanúsítvány- 
kiadó újabb gyermeket fogad maga alá, akkor — váratlanul — 
elfogadjuk majd e gyermek (sőt, unoka) CA által kiadott tanú- 
sítványokat is, hiszen a tanúsítványlánc felépítése során így is 
eljutunk az általunk megbízott gyermek CA-hoz. Ezt nevezik 
Unexpected Trust-nak, hiszen egyáltalán nem biztos, hogy ezt 
mi a Oualified Subordination kiépítése pillanatában előre tud- 
juk, és támogatjuk. 

A dolog kivédése érdekében két beállítással élhetünk: 





A ReguireExplicitPolicy — a Oualified Subordination ak- 

kor érvényes, ha a felépített tanúsítványláncban a 
Oualified Subordination tanúsítvány ,alatt" legfeljebb 
x ,idegen" CA található, ahova bele kell számolni azt 
a gyermek CA-t is, amellyel a  Oualified 
Subordination-t létrehoztuk. 
Például: vegyük a kereszttanúsítást bemutató ábrát. A 
kapcsolat a két gyökérkiadó (CA Ta, CA Tb) között áll 
fenn, korlátozások nélkül tehát az ,a" cégben megbí- 
zunk a teljes ,b" CA hierarchiában. Ha a 
ReguireExplicitPolicy értékét itt például 2-re állítanánk, 
akkor a bizalom csak a CA 1b és a CA 2b-re terjedne 
ki, a CA 3b által kiadott tanúsítványokra már nem. 

A InhibitPolicyMapping — az előzővel teljesen azonos 
elven működik, csak ez az érték nem a Oualified 
Subordination-ra általában vonatkozik, hanem a 
Policy Mapping-ban meghatározott összerendelések- 
re. Ha például az ,a" cég ,x" policy-jét összerendeljük 
a ,b" cég ,y" policy-jével, az InhibitPolicyMapping 2- 
es értéke esetén az összerendelés a CA 1b és CA 2b ál- 
tal kiadott tanúsítványok esetén igen, a CA 3b által 
kiadott tanúsítványokra viszont már nem lenne érvé- 
nyes. 


Az Issuance Policy tehát azt határozza meg, hogy a Oualified 
Subordination ,hidat" milyen módon kiadott tanúsítványok 
járhatják át. 

Az Application Policy meghatározása 


Teljesen ugyanúgy működik, mint az Issuance Policy, csak eb- 
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ben az esetben a tanúsítványok felhasználási módjait korlá- 
tozzuk (a hidas példánál maradva: azt, hogy a Oualified 
Subordination ,hidat" milyen célokra kiadott tanúsítványok 
járhatják át). Az Application Policy-k meghatározása tehát (ne 
feledjük, a policy.inf-be kerül): 





Az Issuance Policy-vel ellentétben az Application Policy-k 
OID-i általában általánosan ismertek és használtak, a Policy 
Mapping-re tehát ritkán van szükség. Ettől függetlenül előfor- 
dulhat, hogy az ,a" cég saját Application Policy-t hoz létre, 
saját OID-vel, és azt összerendeli a ,b" cég OID-ivel: 





Természetesen itt is fennál az Unexpected Trust, és az eszkö- 
zeink is megvannak a kivédésére: 





Két, különálló CA hierarchia összekapcsolása 


Próbáljuk ki az olvasottakat! A két összekapcsolni kívánt CA 
hierarchia a Falatrax Enterprise Root CA által, valamint az 
EladLak Enterprise Root CA által képviselt ,hierarchia" lesz. 
(Miután mindkét hierarchia mindössze egy-egy gyökér CA-ból 
áll, értelemszerűen gyökér CA-kat kapcsolunk majd össze). A 
Oualified Subordination során meghatározzuk, hogy a kap- 
csolat csak felhasználói tanúsítványokra érvényes (Secure 
Email Application Policy, OID: 1.3.6.1.5.5.7.3.4). Korlátoz- 
zuk még a váratlan bizalmat is, bár két érték közül az 
InhibitPolicyMapping beállítására (Policy Mapping híján) nem 
lesz szükség. A teljes — kölcsönös — bizalom érdekében a most 
következő műveleteket kétszer kell végrehajtani (egyszer a 
Falatrax, másodszor pedig az Eladlak tanúsítványkiadóin). 
Mielőtt belekezdenénk a kereszttanúsítás létrehozásába, el- 
lenőrizzük, hogy a tanúsítványkiadók CDP (a CRL elérési útja) 
és AIA (a tanúsítványkiadó saját tanúsítványának elérési útja) 
jól vannak-e beállítva (azaz, az , idegen" szervezetből is elér- 
hetők-e)! 


Kereszttanúsítás-kérés létrehozása 


A kereszttanúsítás létrehozásához az ,idegen" CA saját tanú- 
sítványára, valamint a gualified subordination korlátozásait 
tartalmazó policy.inf fájlra lesz szükségünk. Magát a kereszt- 
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tanúsítást tehát mindenki a saját háza táján kezeli, a 
létrehozásához pedig nem kell kiadni semmi olyan 
információt, ami egyébként nem lenne nyilvános 
(hiszen a CA tanúsítványa az). Üljünk le képzelet- 
ben a Falatrax tanúsítványkiadója elé, és egy könyv- 
tárba mentsük el az Eladlak Enterprise Root CA tanúsítványát! 
(eladlakca.cer). A policy.inf fájl tartalma: 





Első lépésként hozzunk létre egy tanúsítványkérést az Eladlak 
CA meglévő tanúsítványa alapján: 





A varázsló először egy kérésfájl megnyitását ajánlja fel, de mi 
válasszuk a Certificate Files (7.cer) mezőt, és nyissuk meg az 
eladlakca.cer tanúsítványt. Ebből készül a kérés. Ezután a 
policy.inf fájlt kell megadnunk, majd a kérés digitális aláírásá- 


hoz használt tanúsítványt (emlékszünk,  Oualified 
Subordination Reguest Signing). Végül a kész kérést mentsük 
fájlba, mondjuk crosscert.reg néven. 


A kerereszttanúsítvány kiadása 


Ez egy nagyon egyszerű művelet: a Falatrax CA Certification 
Authority MMC konzoljában jelöljük ki a CA-t majd a menü- 
ből válasszuk az AII tasks 2 Submit New Reguest... paran- 
csot, és adjuk meg az előbb elmentett fájl nevét 
(crosscert.reg)! A kész tanúsítványt mentsük el (pl. 
eladlakcross.cer)! 
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212] 





General ] Details ] certification Path 


Certificate Information 





This certificate is intended for the following purpose(s): 
eProtects e-mail messages 
sAllovvs data on disk to be encrypted 
sProves your identity to a remote computer 








7 
[— Issuedto: Eladlak Enterprise Root CA 
— 
e ll Issued by: Falatrax Enterprise Root CA 
a Valid from 2003. 10. 10. to 2005. 10. 10. 
e 
ta 
sz 
Z 
a 
z esta 
s 
a a A kész tanúsítvány: a Falatrax CA adta ki, az Eladlak 
e CA részére, és csak kívánt három dologra érvényes! 
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A tanúsítvány létrehozásával egyidőben a Falatrax CA a saját 
tartományában (az Active Directory-ban) is közzétette a ke- 
reszttanúsítás tényét (valójában magát a tanúsítványt. A 
Falatrax tartomány felhasználói ezért ettől fogva — a meghatá- 
rozott célokra — elfogadják az Eladlak CA tanúsítványait (ha a 
kölcsönösség feltétel, ne felejtsük el a műveletet megismétel- 
ni az Eladlak CA-nál!) 


Kereszttanúsítás Active Directory nélkül 


Előfordulhat azonban, hogy olyan környezetben dolgozunk, 
ahol az Active Directory nem érhető el, a kereszttanúsításra 
azonban mégis szükség lenne. Ha publikusan elérhetővé 
tesszük a kereszttanúsítványt (például egy webkiszolgálón — 
ebből sem lesz baj, hiszen a kereszttanúsítványban sincs pri- 
vát adat — ), akkor megtehetjük, hogy az ellenőrizni kívánt ta- 
núsítványban megjelöljük a kereszttanúsítvány elérési útját. 
Ehhez nyissuk meg az ellenőrizni kívánt tanúsítványt (fontos, 
hogy a .cer fájl ekkor nem jó, csakis a store-unkban már eltá- 
rolt tanúsítványokhoz rendelhetünk ugyanis kereszttanúsít- 
ványt), majd a tanúsítvány tulajdonságlapjának Details olda- 
lán kattintsunk az Edit Properties gombra. (Ha ez a gomb nem 
kattintható, a megnyitott tanúsítványt még nem importáltuk a 
store-unkba). 


ergé zá ai jó Z21x! 


General. Cross-Certificates ] 











[7 specify additional Cross-Certificate download locations 


7 Cross-Certificates Download Interval 


Check every: [8 Hours ] 
Use Default 


TF Cross-Certificates Download URLs—— 





[ http:ZZserver2Ü03/eladlakcross.cer 





OK Cancel Apply 


E A tanúsítványokba , kézzel" is bevéshetjük a CA-k 
közötti kapcsolatot igazoló kereszttanúsítvány elérési 
útját 


Epilógus 

Ezzel elértünk a Windows tanúsítványkiadókat bemutató s0- 
rozatunk végére (is). Én a magam részéről szeretném megkö- 
szönni az Olvasók kitüntető figyelmét, és remélem, az elmúlt 
évek során sok új és hasznos információval lettek gazdagab- 
bak írásaim által. A legközelebbi viszontlátás — olvasás? — re- 
ményében búcsúzom, mindenkinek jó és sikeres munkát kívá- 
nok: 


Fülöp Miklós 
MCSE--Security, MCT 
mick€inetcom.hu 





üÜbjektumorientált 


alkalmazásfejlesztés 


Záró gondolatok 


Sokat gondolkoztam azon, hogy mit lehetne írni a cikksorozat 
befejezéseként. Az elmúlt hónapokban áttekintettük az objek- 
tumorientált fejlesztés alapfogalmait, néhány alapelvét, vala- 
mint emberi tényezőkről is írtam egy-két gondolatot. 

Most ismét a folyamat technikai oldalához térnék vissza, pon- 
tosabban azokhoz a dolgokhoz, amelyek szükségesek ahhoz, 
hogy egy szoftverfejlesztési projekt sikeres legyen. A szakmai 
hozzáértés és a megfelelő emberek kiválasztása mellett 
ugyanis még egy sor módszertan, eszköz és praktika alkalma- 
zására szükségünk van. 

Eszközök terén rendkívül széles a kínálat, szinte el lehet vesz- 
ni a sokféle megoldás között. Az egyes rendszerek különböző 
követelményeknek felelnek meg, így érdemes jó alaposan kö- 
rülnézni, mielőtt eldöntjük, mit fogunk használni. Egy rosszul 
megválasztott eszköz ugyanis súlyos veszteségeket okozhat a 
projektnek. A ,jó ez nekünk, de..." kezdetű mondatok soha 
nem vezettek még jóra. 

Lássuk először az egyik legalapvetőbb igényt, egy vállalati 
ódcentrum létrehozását. Ennek funkcionalítása többféle le- 
het. Elsődleges cél természetesen az, hogy a programkódokat 
egyetlen központi helyen tároljuk, ahova mindenki feltölti a 
saját részét, így mindenki számára elérhetővé válik a minden- 
ori legírissebb verzió. Természetesen a feltöltést kellő körül- 
tekintéssel kell végezni, hiszen egy rosszul megírt komponens 
az egész alkalmazás működését felboríthatja. 

Lássunk egy példát. Tegyük fel, hogy a projekten három fej- 
esztő (vagy három fejlesztőcsoport, a példa szempontjából 
lényegtelen) dolgozik. Az alkalmazás komponensei egymással 
mind kommunikálnak, tehát interfészt kell biztosítanunk bár- 
mely kettő között. 

Ez azt jelenti, hogy mindhárom komponensnek biztosítania 
ell két interfészt, egyet-egyet mindkét másik komponens felé. 
Amennyiben ezek a komponensek lokálisak, azaz egy gépen 
ell elhelyezkedniük, nem pedig hálózati kommunikáció zaj- 
ik közöttük, mindhárom fejlesztő tárol a saját gépén egy-egy 
példányt a másik két fejlesztő kódjaiból is. Természetesen az 
együttműködés így nagyon nehézkes: mindig mindenkinek el 
kell juttatni a legújabb frissítéseket, ügyelni kell arra, hogy az 
egyes verziók kompatibilisek legyenek egymással, mindenki 
gépén ugyanaz a változat legyen stb. Az alábbi ábra ezt az 
esetet szemlélteti: minden fejlesztő minden fejlesztőnek küldi 
a saját komponenseinek verzióit, és minden fejlesztő gépén 
megtalálható minden komponens: 
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1 Minden fejlesztő minden fejlesztővel kapcsolatban áll 


A következő lépés egy központi számítógép kinevezése, aho- 
va mindenki feltöltheti a saját komponensét, így a többszöri 
másolgatásból eredő problémákat kiküszöböljük. Helyette 
azonban szembesülünk azzal, hogy így mindenkinek oda kell 
figyelnie arra, hogy ha kerül a szerverre újabb verzió valamely 
komponensből, azt írissítenie kell lokálisan is, hiszen máskü- 
lönben az egyes fejlesztőknél lévő verziók nem lesznek 
kompatibilisek egymással. Az alábbi ábra ezt a helyzetet 
szemlélteti: 
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Ráadásul arra is oda kell figyelni ebben az esetben, 
hogy ha a szerverre felviszünk egy kódrészletet, az 
felülírja a korábbiakat, így azok sem hibajavítás, 
sem egyéb célokból nem lesznek hozzáférhetők a 
későbbiekben. Erre pedig időnként nagy szükség le- 
het. Gondoljunk arra például, hogy egy nagy rendszert fejlesz- 
tünk, amelyet már a fejlesztés fázisában is elkezd tesztelni egy 
teljesen különálló csapat. Miközben ők a rendszer üzleti logi- 
káját, megvalósítását, külsejét stb. próbálgatják, találnak vala- 
milyen hibát, és ezt jelzik felénk. Nyilvánvalóan ennek a fo- 
lyamatnak időigénye van, ami alatt mi is végezzük saját mun- 
kánkat, azaz a rendszer fejlődik, bővül, változik. Az is elkép- 
zelhető, hogy a régi verziónak már mi is megtaláltuk a gyer- 
mekbetegségeit, így mire a visszajelzés érkezik a tesztelő csa- 
pattól, mi már egy másik rendszerrel dolgozunk ,odabenn", 
amely esetleg már nem is rendelkezik az adott hibával, és 
nem utolsó sorban: belső szerkezete, felépítése is nagyban el- 
térhet a tesztelőknél lévőnél. 

Hasonló gondokat okozhat az is, ha különböző felhasználó- 
nál különböző verziói vannak a rendszernek. Ha ugyanis va- 
lamely felhasználó jelzi felénk, hogy a rendszer nála nem 
megfelelően működik, nem biztos, hogy ugyanaz a verzió ná- 
lunk is megtalálható, hiszen a komponenseket mindig felülír- 
juk a központi táron. 


Újabb előrelépést jelenthet, ha a szerveren verziónként új 
helyre mentjük komponensünket, így a legfrissebb változat is 
hozzáférhető mindenki számára, és a korábbiak is elérhetők 
maradnak. A file-rendszerben ez tehát valahogy így fog ki- 
nézni: 
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- A szerveren az egyes verziókat külön-külön mappák- 
ban tároljuk 


Ebben az esetben is az egyes fejlesztők külön-külön felelőssé- 
ge, hogy a változásokat figyeljék a szerveren, és saját gépükön 
frissítsék a komponenseket, illetve az is, hogy a szerveren 
minden verzió a megfelelő helyre kerüljön. Megoldható vi- 
szont a régebbi verziók elérése, szükség esetén bármikor 
visszagörgethetjük" és igény szerint dolgozhatunk a régebbi 
komponensekkel. 


Az, hogy a fejlesztőktől igényel figyelmet a verziók kezelése, 
rengeteg hiba forrása lehet. Egy elgépelt könyvtárnév, egy vé- 


letlenül felülírt régi verzió beláthatatlan következményekkel 
járhat. 

Erre a problémára jelentenek megoldást az úgynevezett kód- 
centrumok vagy kódmenedzsment eszközök, amelyek auto- 
matikusan elvégzik a verziókezeléssel járó dolgokat. A fejlesz- 
tőknek csak be kell regisztrálniuk kódjukat, és innen kezdve a 
verziók mentése, a verziószám növelése és egyéb teendők is 
automatikusan végrehajtódnak, ezek nem igényelnek külön fi- 
gyelmet. 


Hasonló problémákat vet fel a projekthez kapcsolódó külön- 
féle dokumentumok kezelése is: mind a menedzsment, mind 
a tervezés és fejlesztés oldalán születnek olyan specifikációk, 
elemzések, iratok, amelyek historikus rögzítése elengedhetet- 
len. Ehhez is rendelkezésre állnak különféle dokumentumke- 
zelő rendszerek. 


A fenti megoldások azonban felvetnek egy igen fontos kérdést: 
mi történik akkor, ha ugyanazon a kódon vagy dokumentu- 
mon többen is dolgoznak egyszerre? Ha ezt a problémát nem 
kezeljük megfelelően, előfordulhat, hogy a későbbi mentések 
mindig felülírják a korábbiakat, így bizonyos változtatások el- 
vesznek. 

Amennyiben a file-hoz egyetlen ember férhet csak hozzá, a 
munka akadozik, sőt az is előfordulhat, hogy hosszabb időre 
is leáll, például mert valaki elfelejtette ,elengedni" az adott 
dokumentumot, és közben elment nyaralni Java szigetére. 
(Elnézést kérek mindenkitől, de .NET sziget sajnos még 
nin 0) 

A kész rendszerek ezekre a problémákra is megoldást nyújta- 
nak az úgynevezett check in — check out segítségével. Amikor 
a felhasználó (fejlesztő, rendszertervező, menedzser stb.) egy 
file-on szeretne dolgozni, annak egy lokális példányán megte- 
heti azt. Amikor munkájával végzett, és be szeretné regisztrál- 
ni a módosításokat, a rendszer megnézi, más is változtatott-e 
az adott file tartalmán az eltelt idő alatt. 

Amennyiben nem történt változás, nincs probléma, a doku- 
mentum vagy kód egyszerű bemásolása és a verziószám leke- 
zelése elegendőnek bizonyul. Gond akkor adódik, ha közben 
valaki más már módosított bizonyos dolgokat. Az összefésülés 
már nem bízható teljesen a rendszerre, hiszen ennek logikája 
minden egyes alkalommal más és más lehet, feltétlenül szük- 
ség van az emberi közreműködésre. 

Az összefésülés előnye, hogy minden módosításról külön-kü- 
lön eldönthetjük, hogy megtartjuk-e avagy eldobjuk. Így egy 
dokumentum élettörténete például az alábbiak szerint alakul- 
hat: 
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B A dokumentumok összefésülésének eredménye 


Mind a dokumentumokhoz, mind a programkódokhoz szer- 
vesen kapcsolódik a dokumentációgenerálás. Ez többnyire 
úgy történik, hogy vagy a tervező- vagy a fejlesztőkörnyezet 
lehetőséget biztosít automatikus dokumentumgenerálásra 
(többnyire HTML és/vagy RTF formátumban). A dokumentu- 
mok különböző UML diagramokból, hozzájuk tartozó kódok- 
ból, paraméterekből és szöveges megjegyzésekből állnak, for- 
mátumuk és pontos tartalmuk rendszerfüggő. 


Ha már a kód- és dokumentumkezelést megoldottuk és gördü- 
lékenyen halad a fejlesztés, illik odafigyelni a rendszerrel kap- 
csolatos hibák kezelésére és feldolgozására is. A rendszer 
tesztelése alapvetően három szinten zajlik: 

1. fejlesztői tesztek 

2. üzleti és üzemeltetői tesztek 

3. felhasználói tesztek 


tech.net GW. 4 TF 4: a max a 


A fejlesztői teszteket értelemszerűen a fejlesztők 
végzik, a rendszer finomítása közben. Enélkül nem 
is fejlesztés a fejlesztés, hiszen ki látott már olyan 
kódot, ami elsőre fordult és hibátlanul futott 
volna?... 

Az üzleti és üzemeltetői teszteket már külön tesztelésre sza- 
kosodott csapat végzi, a felhasználói tesztek pedig a végfel- 
használónál történnek: vagy dedikáltan tesztelés céljából 
átadjuk a rendszert, vagy az éles átadás után, a használat s0- 
rán derül fény néhány hibára, hiányosságra. 

A tesztelés valamennyi fázisában szükségszerű, hogy legyen 
egy központi hely, ahol a teszteredményeket, hibajelentése- 
ket tárolhatjuk. Ehhez tehát a fent említett valamennyi sze- 
replőnek hozzá kell férnie, természetesen a megfelelő jogo- 
sultságokkal. Így aztán mindenki egységes felületen dolgoz- 
hat: itt rögzíthetők a tesztesetek, a hibajelenségek, itt lehet a 
hibát delegálni az illetékes fejlesztőnek vagy fejlesztőcso- 
portnak, itt lehet rögzíteni a hibajavítás tényét stb. Így aztán 
maguknak a hibáknak is saját életciklusuk van, amely rend- 
szerről rendszerre változik, az alapmotívumok azonban álta- 
lában ugyanazok: a hibát észlelő személy beregisztrálja a hi- 
bát, amelynek státusza ekkor még nyitott. A vezető fejlesztő 
(vagy az ezért felelős személy) hozzárendeli azt az érintett 
fejlesztőhöz, akinek a felelőssége a hiba javítása. A fejlesztő 
erről értesítést kap, majd a hiba javítása után bejelöli ennek 
tényét a rendszerben. Újabb teszteléssel ellenőrzésre kerül, 
hogy a hiba valóban kijavításra került-e, és ha igen, a hiba le- 
zárható. Amennyiben mégsem tökéletes a javítás, újabb kö- 
rök kezdődnek. 


Honnan tudhatjuk azonban, hogy mi számít hibának és mi 
nem? Természetesen a technológiai bukások minden esetben 
(a rendszer lefagyása, rendellenes viselkedése stb.), az üzleti 
hibázásokkal azonban sajnos nem ilyen egyértelmű a helyzet. 
Itt ugyanis egyértelműen tudni kell, mik a rendszerrel szem- 
ben támasztott igények, pontosan milyen üzleti folyamatokat 
valósít meg. Sajnos sok esetben a nem elég precíz specifiká- 
ció rengeteg félreértéshez vezet, a megrendelő ugyanis beleért 
olyan dolgokat is, amelyek a rendszer tervezőinek és fejlesz- 
tőinek eszébe sem jutottak. (Lásd előző havi cikkem.) 
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B A hibajavítás folyamata 


A fent említett problémákra természetesen megoldást jelenthet 
egy jó specifikáció. Ha ugyanis a specifikáció kellően pontos 
és részletes, nincs lehetőség arra, hogy belemagyarázzunk 
dolgokat. A jó specifikáció ugyanis nemcsak azt tartalmazza, 
hogy mit kell tudnia a megvalósítandó rendszernek, hanem 
azt is, hogy mi nem célja a futó fejlesztési projektnek. Így (op- 
timális esetben) a szállító és a megrendelő között nem merül- 
hetnek fel félreértések. 

A jó specifikáció alapfeltétele a megrendelő (a későbbi fel- 
használó) igényeinek pontos rögzítése. Ennek egyik oldalát, a 


Use Case-ek (használati esetek) alkalmazását korábban már 
bemutattam. Most a technológiai háttérre, a különböző esz- 
köztámogatottságra térnék ki. 

Maguk a használati esetek, és általában az UML modellek ke- 
zelésére számtalan eszköz áll rendelkezésünkre. Az igényfel- 
mérés azonban sokkal több UML diagramok rajzolásánál. Az 
igényeket rendezetten, könnyen elérhető, hozzáférhető mó- 
don kell tárolni. Ez alatt azt értem, hogy ha a követelménye- 
ket áttekinthető, rendszerezett formában tároljuk, a későb- 
biekben arra rendkívül egyszerűen hivatkozhatunk a fejlesztés 
bármely fázisában. 

Szokás szerint valamilyen hierarchikus sorszámozást alkalma- 
zunk. Ennek felhasználása a későbbiekben úgy történik, hogy 
egyrészt a dokumentációkban is eszerint hivatkozunk rá (így 
egyértelmű, mire gondolunk, nem kell barokk körmondatok- 
kal körülírni az adott követelményt), másrészt a kódok kom- 
mentezésében, ezáltal az egyes kódrészletek megértésében is 
sokat segíthet, ha szerepeltetjük, hogy az adott eljárás ponto- 
san melyik funkciót valósítja meg. 

Az igények pontos rögzítése a tesztelésnél is nagy segítséget 
nyújthat. A ,hibagyanús" üzleti momentumokról pillanatok 
alatt kiderülhet, hogy valóban hibáról van-e szó, vagy pusztán 
olyan dologról, amit mi nem így csinálnánk, de a specifikáció 
szerint a megvalósítandó rendszer célja ez volt. Így a teszte- 
setek és a hibák rögzítésénél egyaránt hivatkozhatunk a köve- 
telmény- illetve a funkcióspecifikáció megfelelő pontjaira, ez- 
zel is megkönnyítve kollégáink dolgát. 


És ha mindezen feltételek teljesülnek? Akkor minden bi- 
zonnyal olyan körülmények között dolgozhatunk, amelyek 
nagyban elősegítik a sikeres fejlesztési folyamatot. A fentieket 
kiegészíthetjük még különböző tervezési illetve fejlesztési 
ajánlások bevezetésével, alkalmazásával. Ilyenek lehetnek 
például az MSF (Microsoft Solutions Framework) vagy a RUP 
(Rational Unified Process) stb. 


A fentiek bevezetéséhez azonban a fejlesztő cég belső kultú- 
ráját, működését kell először is feltérképezni, majd meghatá- 
rozni a szükséges előrelépéseket. Ehhez azonban alapos kö- 
rültekintésre és felkészülésre van szükség, hiszen a rosszul 
előkészített változtatások ellenérzést váltanak ki munkatár- 
sainkból, és az elérni kívánt célok meghiúsulnak. 


Ehhez kívánok mindenkinek sok sikert és kitartást! 


Molnár Ágnes 
Molnar.AgnesGcleware.hu 
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